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INTRODUCTION 


• Data  Processing  managers  have  been  concerned  with  the  migration  of 
hardware  and  with  planning  for  capacity  utilization  since  third  generation 
systems  appeared  in  the  mid-1960s. 

• Planning  for  software  migration  is  known  to  be  as  important  an  issue,  but 
nowhere  near  as  tangible  or  predictable  as  the  growth  in  hardware. 

• Contemporary  management  issues,  such  as  the  change  from  centralization  to 
decentralization  (or  vice  versa),  the  competitive  pressures,  user  demands  for 
more  on-line  systems,  the  increasing  role  of  government  regulations  even  in 
the  standard  G&A  applications,  coupled  with  the  imminent  appearance  of 
another  new  generation  of  hardware  produce  software  planning  uncertainties 
that  are  difficult  to  deal  with. 

• This  report,  provided  as  a part  of  INPUT'S  Planning  Service  For 
Computer/Communications  Users,  analyzes  the  trend  of  systems  software 
development  in  relation  to  the  hardware  on  which  it  operates  and  the 
organizational  framework  in  which  it  is  situated. 

• Current  developments,  driving  forces,  organizing  principles,  and  likely  future 
developments  are  all  examined  as  to  their  roles  and  impacts  on  the  software 
development  process. 
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• In  conjunction  with  the  study,  a survey  of  26  major  computer  users  (IBM 
370/158  or  larger)  and  16  major  software  vendors  was  conducted. 

• Their  responses  have  been  included  in  the  report  where  appropriate,  and  a 
summary  of  respondent  characteristics  and  a copy  of  the  questionnaires  are 
included  in  the  appendices. 

• A collateral  report  entitled  "Opportunities  in  Marketing  Systems  Software 
Products"  has  been  produced  as  part  of  INPUT'S  Marketing  Analysis  Service, 
examining  this  topic  from  the  point  of  view  of  the  commercial  software 
vendor.  Questions  concerning  the  availability  of  this  report  should  be  directed 
to  Michael  Burwen,  Vice  President  of  Marketing,  at  INPUT'S  Palo  Alto  office. 

• Comments  and  inquiries  from  clients  are  invited. 
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II  EXECUTIVE  SUMMARY 


II 


EXECUTIVE  SUMMARY 


A.  HISTORICAL  BACKGROUND 


• Prior  to  I960,  data  processing  was  conceptually  one-dimensional.  Hardware 
and  software  were  matched  one  for  one,  vendor  to  vendor. 

Systems  software  was  virtually  non-existent,  except  for  a few  language 
assemblers  and  interpreters. 

Organizationally,  applications  were  restricted  largely  to  the  corpo- 
ration comptroller's  or  chief  financial  officer's  domain. 

• With  the  advent  of  the  transistor-driven  "second  generation,"  data  processing 
took  on  a whole  new  seriousness.  Practical  applications  for  operating 
departments  became  possible,  and  both  the  number  of  computers  installed  and 
their  supporting  staff  proliferated. 

Systems  software  took  the  form  of  language  compilers,  sorting  and  file 
transfer  utilities,  generalized  input/output  routines,  an  interruptible 
systems  monitor;  and  the  first  inklings  of  generalized  retrieval 
programs  became  popular. 

The  hardware  vendors,  large-scale  users,  and  user  associations  were 
still  the  main  vehicle  for  the  production  of  systems  software,  but 


- 3 - 


© 1979  by  INPUT,  Palo  Alto,  CA  94303.  Reproduction  Prohibited. 


INPUT 


portability  and  standards  began  to  be  fervent  issues  as  the  competition 
between  vendors  heated  up. 

As  applications  multiplied,  so  did  the  number  of  computer  centers,  and 
decentralization  (often  approaching  a total  lack  of  organizational 
control)  was  the  order  of  the  day. 

The  mid- 1 960's  saw  the  introduction  of  the  "third  generation"  of  hardware, 
incorporating  large  scale  integration,  large  internal  memories  and  external 
data  storage,  and  the  increasing  availability  of  remote  interactive  terminals. 
But  the  dislocation  in  software  would  be  traumatic. 

Even  though  hardware  costs  were  dropping  by  an  order  of  magnitude, 
the  new  applications  would  "eat  up"  that  difference  and  more. 

In  order  to  justify  the  costs  of  the  new  machines,  economies  of  scale 
had  to  be  employed.  This  required  a strong  move  to  centralize  the  far- 
flung  data  processing  functions,  and  to  couple  them  with  multi-user, 
multi-programming  modes  of  operation. 

To  support  this  complexity,  new  types  of  systems  software  were 
required,  including  operating  systems,  telecommunication  monitors, 
language  conversion  programs,  specialized  language  processors, 
simulators,  emulators,  and  other  esoterica. 

Companies  began  to  spring  up  to  develop  and  sell  some  of  these 
"software  packages,"  even  though  vendor  software  was  still  provided 
free  of  charge.  The  selling  points  included  better  efficiency,  lower 
operating  cost,  and  improved  functionality. 

Then  came  1969,  when  IBM  was  forced  to  unbundle  its  software,  and  the 
outside  software  market  began  to  "take  off." 

Two  factors  complicated  the  DP  manager's  life. 
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Organizationally,  users  were  strongly  resisting  the  requirement  for 
centralization,  anticipating  loss  of  control,  poorer  service,  higher  costs, 
and  in  many  cases  receiving  all  three. 


Technically,  higher  levels  of  hardware  sophistication  and  complexity 
were  calling  for  software  skills  that  were  in  short  supply.  Deadlines 
were  missed,  promises  left  unfulfilled,  and  credibility  was  often  totally 
destroyed. 

By  the  early  to  mid- 1 970's,  new  hardware  and  software  tools,  new  business 
understanding,  and  new  organizational  alignments  had  fallen  into  place  to 
allow  a new  phase  in  data  processing  to  begin. 

The  declining  costs  of  on-line  storage,  the  introduction  of  virtual 
memories,  and  the  development  of  data  base  management  systems 
fostered  the  growth  of  "management  information  systems"  that  were 
cost  effective  at  the  corporate  level,  not  just  at  the  operating 
department  level. 

Users  in  a few  organizations  began  to  understand  the  value  of  inter- 
active operational  support  systems,  and  demanded  more  and  more  of 
these  services.  In  order  to  resolve  competing  demands  for  scarce 
development  and  operating  DP  resources,  user  chargebacks  were  widely 
imposed. 

Another  new  set  of  systems  software  was  called  for,  including  job 
schedulers,  job  accounting  routines,  program  librarians,  disk  space  and 
tape  library  management  programs,  performance  evaluators,  language 
optimizers,  preprocessors,  development  aids,  retrieval  systems,  and 
data  base  management  systems— the  most  important  of  all. 

For  the  first  time,  independent  software  vendors  began  to  number  their 
installations  in  the  hundreds,  and  use  of  their  products  became  a valid 
business  judgment  by  the  users,  not  a brave  experiment. 
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• From  the  mid-1970's  to  the  present  has  been  a consolidation  and  control  phase. 
EDP/MIS  departments  have  established: 

Planning  groups  to  control  and  forecast  hardware  acquisition. 

Technical  assistance  groups  to  fine-tune  hardware  and  network 
performance. 

Project  management  teams  to  control  software  development. 

EDP  steering  groups  to  control  user  involvement  and  priority  setting. 

• But  another  new  phase  is  just  around  the  corner,  triggered  by: 

New  generation  hardware  announcements. 

A growing  demand  for  return  to  decentralized  control  and  access  to 
information  in  the  form  of  DDP. 

A forecasted  shortage  of  DP  professional  personnel. 

New  software  technologies  that  could  finally  put  control  back  in  the 
hands  of  the  user. 

Business  opportunities  and  demands  that  are  forcing  cross-industry 
integration  of  applications. 


B.  CURRENT  AND  FUTURE  SOFTWARE  DEVELOPMENTS 


• The  most  significant  driving  force  affecting  the  course  of  software  develop- 
ment for  the  coming  five  year  period  is  the  swing  back  toward  decentral- 
ization in  data  processing  - - but  with  a difference. 
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This  time,  forward-thinking  organizations  are  prepared  to  analyze  not 
only  the  benefits,  but  also  the  costs  of  decentralization. 

Only  those  functions  that  make  business  and  economic  sense  will  be 
distributed  to  remote  locations. 

Studies  conducted  by  INPUT  reveal  a shift  toward  decentralization  that  has 
increased  from  13%  decentralized  to  more  than  20%  decentralized  over  the 
past  18  months  (see  Exhibit  ll-l). 

The  second  driving  force  that  is  affecting  current  software  development  and 
will  continue  to  do  so  for  the  next  five  years  is  the  provision  of  improved 
functionality  to  end  users,  largely  through  a trend  to  more  on-line  systems. 
Also  there  will  be  increasing  use  of: 

Electronic  mail. 

Word  processing. 

Less  important  than  either  of  the  previous  driving  factors,  but  still  important 
enough  to  be  considered  as  prevailing  reasons  for  new  software  development, 
are: 


Reduced  cost  (although  harder  and  harder  to  justify  now  by  "replace- 
ment of  personnel"). 

Obsolescence  of  old/availability  of  new  technology  (but  only  if  change 
is  essential,  or  accompanied  by  other  reasons). 

Improved  efficiency/performance  (if  the  life  cycle  of  the  hardware  can 
be  extended). 

Company  growth/business  changes  (a  key  opportunity  for  DP 
management  to  move  into  strategic  top  management). 
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EXHIBIT  11-1 


SHIFT  SN  CENTRALIZATION  /DECENTRALIZATION 
SINCE  FEBRUARY  1978 


FEBRUARY 
1 978 


OCTOBER 
1 978 


JUNE/JULY 
1 979 


CENTRALIZED 


□ 

El 


DECENTRALIZED 

BOTH 
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Government  regulation  and  other  miscellaneous  factors. 


Exhibit  11-2  shows  the  relative  importance  of  each  of  these  factors. 

To  maximize  the  value  of  any  newly  developed  software,  DP  managers  must 
assure  that  the  principles  of  standardization,  generality,  reuse  of  existing 
resources,  and  freedom  from  high  training  and  skill  requirements  be  adhered 
to,  or  forfeit  the  possibility  of  improved  productivity. 

Specific  techniques  that  have  proven  useful  are  the  establishment  of  an 
independent  software  quality  control  assurance  group,  greater  use  of 
packaged  software  (even  if  it  means  bending  requirements  slightly  to  fit 
the  software,  rather  than  vice  versa),  and  greater  involvement  of  the 
end  user  in  defining  and  even  producing  his  new  software. 

Sixty  percent  of  the  DP  managers  surveyed  said  their  end  users  would 
be  getting  more  involved  in  software  development  in  the  next  two  to 
five  years. 

This  trend  implies  a large-scale  need  for  formal  training  of  end  users 
that  DP  managers  should  begin  planning  now. 

COBOL,  FORTRAN,  PL/ 1,  and  certainly  Assembler  are  "dead  languages"  as 
far  as  their  accessibility  by  end  users  is  concerned,  and  DP  managers  must 
look  to  the  non-procedural  languages  to  achieve  user  productivity  (even  at  the 
cost  of  decreased  machine  productivity). 

DP  organizations  can  begin  now  to  gain  valuable  experience  through  the 
use  of  remote  computing  services  which  offer  the  distributed  network 
together  with  an  assortment  of  non-procedural  languages  such  as 
RAMIS  and  NOMAD. 

Additional  software  packages  to  support  distributed  data  bases  are 
expected  to  be  on  the  market  within  two  years,  coinciding  with  the 
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EXHIBIT  11-2 


REASONS  FOR  CHANGES  IN  SOFTWARE 


MEET 


TECHNOLOGY 


PERCENTAGE  OF  TOTAL  MENTIONS  AS 
DRIVING  FACTORS  FOR  CHANGE 
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expressed  interest  of  46%  of  the  respondents  to  this  study  in  estab- 
lishing distributed  data  bases  in  two  to  five  years. 

• Nevertheless,  distributed  data  bases  do  not  necessarily  provide  easier  or  better 
access  to  data.  In  specific  cases  they  may  be  most  cost-effective  because 
they  reduce  communications  costs.  They  may  be  more  reliable  because  they 
are  smaller,  provided  more  redundancy  in  the  system,  and  reside  closer  to  the 
owner.  But  they  may  be  none  of  these. 

Consequently  DP  managers  should  move  slowly  toward  distributing  their 
data  bases  unless  there  are  other  compelling  business  reasons  to  do  so. 

• The  guiding  principle  to  achieving  improved  productivity  in  software  develop- 
ment is  to  concentrate  on  improvements  in  effectiveness,  which  shows  up 
more  directly  in  the  corporation’s  bottom  line. 

• A new  software  effectiveness  product  which  may  be  available  from  IBM 
is  a relational  data  base  (System  R)  which  has  undergone  beta  tests.  This 
uses  a non-procedural  language  known  as  "SQL"  (Sequel). 

This  will  not  force  a replacement  of  IMS  and  DL/1,  but  can  be  used  in 
combination  with  those  earlier  products  to  produce  equivalent  machine 
performance,  with  much  greater  ease  of  use. 

Extensive  portions  of  the  RDB  and  NPL  software  will  be  implemented 
in  SCP  microcode  and  in  the  disk  storage  controllers  themselves. 

For  smaller  data  bases  (up  to  one  billion  bytes),  existing  products  on 
PDP-I  I minicomputers  offer  the  same  kinds  of  conceptual,  easy  to  use 
advantages.  Typical  products  of  this  class  are  ADMINS- 1 I,  RISS, 
SIMILE,  and  ORACLE. 
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The  linking  of  word  processing  to  data  processing  offers  effectiveness 
improvement  potential,  but  primarily  from  those  applications  which  require 
both  capabilities  such  as: 

Preparation  of  engineering  and  contract  specifications  and  proposals. 

Preparation  of  software  documentation,  and  sales  and  procedure 

manuals. 

Professional  client  billing. 

Electronic  mail. 

If  this  potential  is  to  be  achieved,  it  must  be  controlled  by  the  DP  manager 
from  the  beginning,  even  though  this  may  mean  getting  involved  initially  with 
myriads  of  small,  standalone  systems. 

Electronic  mail  software  on  minicomputers  is  commercially  available  today, 
but  lack  of  standards  and  appropriate  tariffs  and  fees  restrict  it  pragmatically 
to  intra  company  use. 

DP  managers  in  this  survey  were  more  eager  quantitatively  and 
qualitatively  to  implement  electronic  mail  than  major  software  vendors 
are  to  support  it  on  large  scale  hardware. 

Nevertheless,  IBM  has  been  experimenting  with  an  in-house  system  in 
Europe,  using  the  European  IBM  PABX,  and  may  be  expected  to  enter 
the  U.S.  market  in  about  five  years  when  the  regulatory  issues  are 
resolved. 

Minicomputer  vendors  are  moving  more  rapidly  to  introduce  EM 
systems,  with  several  systems  recently  announced. 
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Effectiveness  improvements  resulting  from  the  use  of  electronic  mail 
are  estimated  to  average  5%  of  the  value  of  middle  and  top  manage- 
ment time. 

• Integrated  office  systems  and  management  workstations  are  rated  low  in  value 
by  DP  managers  and  major  software  vendors. 

INPUT  believes  this  is  an  emotional  response  typical  of  the  attitudinal 
restructuring  that  will  be  required  by  the  "Office  of  the  Future,"  rather 
than  a reflection  of  the  technology  required. 

Because  of  this  need  for  attitudinal  change,  INPUT  recommends  a low 
key,  incremental  approach  that  is  sold  from  the  bottom-up,  i.e., 
directly  to  the  office  staff  in  a cooperative  department— perhaps  the 
DP  manager's  own. 

• Improvements  to  the  efficiency  of  the  systems  development  process  are  more 
likely  to  flow  from  several  of  the  effectiveness  tools  already  outlined  (such  as 
relational  data  bases  and  non-procedural  languages)  than  from  any  near-term 
technological  breakthroughs  in  software  development  techniques. 

• However,  there  will  almost  certainly  be  more  widespread  use  of  the  standalone 
minicomputer  hardware/software  combination  known  as  "Programmer's 
Workbench"  or  "Maestro,"  to  name  two  existing  examples. 

• By  extension  forward  to  the  design  process,  a "Systems  Workbench"  would 
provide  minicomputer-aided  system  design  tools  to  enable  the  analyst  to 
achieve  greater  productivity. 

Aids  will  include  integrated  access  to  data  dictionaries,  system 
definition  languages,  system  flowcharters,  logic  checkers,  provability 
theorems,  and  the  like. 
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Software  vendors  agree  that  this  product  is  almost  a certainty  within 
five  years,  and  very  likely  to  make  an  appearance  within  two  years. 

• Automatic  Program  Testers  have  been  used  in  research  environments,  and  a 
number  of  them,  such  as  DAVE,  PET,  RXVT,  DISSECT,  CASEGEN,  EFFIGY, 
and  SELECT,  have  shown  some  promise. 

2 

Performance  is  a problem  because  of  the  necessity  for  tracing  n paths 
in  a program  of  n nodes. 

These  checkers  cannot  catch  the  33%  of  errors  that  occur  in  the  design 
and  specification  phase. 

However,  because  of  their  promise  of  value  against  the  other  two-thirds 
of  the  errors,  software  vendors  expressed  a better  than  even  probability 
that  automatic  program  testers  would  be  commercially  available  within 
two  years. 

• Automatic  programmers  include  those  tools  that  translate  machine-inde- 
pendent pseudocode  automatically  into  any  desired  machine  code,  and  those 
tools  (like  some  non-procedural  languages)  that  accept  a definition  of  what  is 
to  be  done,  then  construct  a suitable  sequence  of  instructions  to  do  it. 

Currently  available  non-procedura!  languages  have  already 
demonstrated  the  capability  of  reducing  development  time  from  months 
to  days  for  suitable  applications. 

This  situation  permits  a "throwaway"  code  approach  to  poorly  definable 
situations,  so  that  in  a short  period  of  time  successive  iterations  of 
design  can  form  the  basis  for  closer,  better  informed  approaches  to  the 
desired  solution. 
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Software  vendors  are  twice  as  convinced  as  DP  managers  that  new  and 
improved  products  of  this  type  will  be  available  within  two  to  five 
years. 

• Miscellaneous  other  software  development  products,  such  as  data  translators, 
automatic  content  indexers,  and  multi-media  source  data  converters  may  also 
become  available  within  five  years. 


C.  RECOMMENDATIONS 

I.  ORGANIZATIONALLY 

• The  EDP  department  and  the  end  users  must  develop  a working  partnership  to 
assure  that  the  data  processing  resource  becomes  a true  corporate  data 
resource.  The  EDP  department  should  take  the  initiative  in  securing  greater 
user  involvement  and  understanding. 

A cooperative,  mutual  learning  approach  is  best  to  break  down  user 
reluctance  and  suspicion. 

Consistency  of  response  to  the  user  interface  is  of  paramount 
importance. 

• Users  must  assure  that  the  right  applications  receive  priority  treatment. 

Take  an  affirmative,  leading  role  in  EDP  strategy  formulation  for  the 
corporation. 

Recruit  knowledgeable  DP  staff  into  mainline  departments  by 
establishing  attractive,  senior  level  transfer  career  paths. 
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Train  key  users  in  EDP  concepts  and  techniques,  so  that  they  may 
communicate  on  an  equal  basis  with  EDP  professional  staff. 

Establish  a technique  that  fits  the  management  style  of  the  organization  to 
resolve  conflicts  and  determine  whether  corporation  priorities  should 
supercede  local  priorities. 

No  single  technique  has  been  pre-eminently  successful  for  any 
organization. 

A pragmatic  approach  is  best.  Try  an  EDP  steering  committee,  a 
standards  audit  and  enforcement  group,  or  the  freedom  for  users  to 
contract  for  cost-effective  outside  services. 

TECHNICALLY 

Emphasize  human  engineering  in  new  systems  design  and  retrofitting  of  old 
applications. 

Possibility  for  committing  user  error  should  be  minimized. 

Errors  that  slip  through  should  "fail-soft,"  and  not  cause  catastrophic 
destruction  of  data  or  unavailability  of  the  system  to  other  users. 

The  user  interface  should  be  simple,  intuitive,  and  accessible.  Light 
pens,  touch  panels,  color/graphics  can  all  contribute  to  this  design  goal. 

Be  prepared  for  more  and  more  of  current  applications  software  to  be 
subsumed  by  systems  software  functions. 

The  System/38  provides  an  example,  where  entire  programs  can  be 
written  in  the  operator's  command  language. 
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Microcode,  very  large  storage  capacities,  and  parallel  (pipeline) 
processing  will  deliver  reasonable  perceived  performance,  while 
dropping  hardware  unit  costs  will  compensate  for  the  increased 
hardware  resources  required. 

Lower  development  costs  will  more  than  cover  any  residual  higher 
operating  costs. 

• Look  for  adequate  systems  software  to  be  available  within  the  next  two  to  five 
years  (some  is  available  now)  to  support  distributed  processing  in  a number  of 
alternative  modes: 

Main  (central)  host-driven  star  networks  utilizing  303X  hardware,  MVS 
or  MVSE  with  SNA  control  programs,  and  large  370  class  hardware  at 
the  nodes  (which  in  one  or  two  years  will  be  cost-effective). 

A similar  system  utilizing  4300  or  8100  hardware  at  the  nodes,  at  first 
in  a centrally  controlled  and  centrally  programmed  configuration,  but 
later  evolving  into  a ring-driven,  "no  host"  network.  This  alternative  is 
also  a year  or  more  away  for  most  organizations,  based  on  IBM's 
announced  delivery  dates. 

A loosely  coupled,  decentralized  configuration  using  non-IBM  mini- 
computer hardware  at  the  nodes,  each  with  its  own  local  data  base. 
Users  will  have  to  be  responsible  for  developing  much  more  of  the 
systems  software  themselves  for  this  configuration. 

• Determine  from  a management  point  of  view  which  applications  must  be 
operated  and  controlled  centrally,  and  which  must  be  operated  and  controlled 
locally. 

All  others  are  candidates  for  either  centralization  or  decentralization, 
based  on  individual  technical,  cost,  and  priority  factors. 
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Cost  analyses  should  incorporate  to  the  fullest  possible  extent  the  re- 
use at  nodes  of  existing  software  that  has  already  been  partially  or  fully 
amortized. 

The  opportunity  to  use  multiple  copies  of  software  at  nodes  that  has 
been  previously  used  only  in  a single  copy  centrally  may  furnish  a 
midlife  software  performance  "kicker"  due  to  lower  local  transaction 
volume  and  time  demands. 
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Ill  HISTORICAL  DEVELOPMENT 


A.  HARDWARE  CONSTRAINTS 


• Sn  I960,  IBM  was  faced  with  two  financial  pressures: 

1401s  were  starting  into  production  as  the  business-oriented  machine 
that  brought  true  "computing"  within  the  availability  of  thousands  of 
firms.  The  vast  majority  (90%)  were  sold  on  a monthly  availability 
charge  (MAC)  and  only  recovered  manufacturing  and  marketing  costs 
for  IBM  after  approximately  20  months. 

Corporate  commitments  to  new  semiconductor  research,  computer 
developments  (360),  expanded  manufacturing  facilities,  hiring  additional 
field  hardware/software  support  staff  caused  cash  flow  problems. 

For  the  first  time  in  IBM’s  history,  salesmen  were  assigned  purchase 
targets.  These  were  confined  to  older  electronic  accounting  machines 
(EAM  402,  407,  602...).  The  notion  of  customers  owning  their 
computers  and  accounting  machines  was  encouraged. 

• Honeywell  announced  the  H200  in  November  1963.  The  price/performance  was 
approximately  2.5  to  ! over  the  1401  and  1410. 
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The  H200  was  not  instruction  set  compatible.  However,  all  IBM  source 
and  object  programs  could  be  recompiled  with  the  aid  of  Honeywell’s 
"Liberator." 

Honeywell  had  to  supply  the  operating  system  (in  reality,  only  a disk 
and  tape  monitoring  system). 

• IBM  prematurely  announced  the  360  series  in  April  1964,  largely  as  a reaction 
to  Honeywell’s  200  series.  Initial  versions  of  the  operating  systems  came  out 
over  a two  year  period. 

By  mid  1966,  IBM's  360  systems  software  was  operational  but  highly 
inefficient. 

During  this  two  year  period,  Honeywell  replaced  many  IBM  1401s  and 
1410s  where  prospects  were  interested  in  cost  savings,  performance  and 
delivery. 

• RCA  recognized  the  opportunity  to  produce  a functionally  similar  computer 
and  fill  the  demand  vacuum  created  by  IBM's  delivery  and  software  problems. 

RCA  initiated  a much  less  ambitious  operating  system  (similar  to  IBM's 
DOS). 

By  the  time  RCA's  Spectra  Series  became  more  readily  available,  IBM 
could  deliver  360s  in  reasonable  time  and  IBM's  OS  was  more  efficient. 
RCA's  attempts  at  technological  innovations  caused  RCA  to  lose  the 
"window  of  opportunity"  during  that  valuable  year  of  1967. 

Because  RCA's  Spectra  was  not  identical  at  the  instruction  set  level 
and  because  a few  conversion  problems  were  encountered,  RCA's  sales 
tended  to  be  less  "replacement  of  360  sales"  and  more  new  computer  or 
extra  capacity  type  sales. 
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IBM  announced  new  operating  systems  and  more  modular  computers 
(370/ 1 35,...  1 65)  in  June  of  1970.  By  this  time,  used  360/40s  and  50s 
with  PCM  peripherals  on  third  party  leases  were  far  more  cost 
effective  than  offerings  from  RCA,  Honeywell,  and  others,  so  that  by 
the  early  1970s,  the  leasing  companies  and  peripheral  PCMs  were 
prospering. 

• However,  1972  was  a year  of  major  legal  problems  for  IBM,  involving  both  a 
major  competitor,  Control  Data  Corporation  (CDC),  and  the  U.5.  Justice 
Department.  Since  the  fastest  growing  data  processing  segment  in  1972  was 
the  computer  services  industry,  IBM  found  a way  to  temporarily  solve  both  the 
CDC  and  Justice  Department  legal  actions. 

IBM  sold  its  U.S.  Service  Bureau  Corporation  to  CDC. 

CDC  agreed  to  drop  all  charges  and  to  destroy  its  "evidence  of  IBM 
predatory  pricing." 

The  Justice  Department  was  only  partially  satisfied. 

• Minicomputers  with  systems  software  limited  to  specific  tasks  were  now 
beginning  to  encroach  on  IBM's  360/20  and  30  marketplaces.  Using  new 
emulator  technology,  Digital  Scientific  of  San  Diego,  in  1972,  developed  a high 
performance  IBM  I 130  and  1800  minicomputer  emulator.  This  Meta  computer 
appealed  to  firms  that  already  had  a large  investment  in  1130  and  1800  based 
software. 

• Dr.  Eugene  Amdahl  had  been  in  IBM  development  labs  for  almost  20  years.  He 
viewed  the  370/168  as  "stretching"  slow  semiconductor  and  design  technology 
more  appropriate  for  the  158.  He  and  some  other  IBM  designers  decided  to 
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design  a semiconductor  logic  family  that  would  be  aimed  at  very  large 
computer  architecture  without  regard  for  midrange  computer  economics. 
Working  with  Motorola,  Amdahl  designed  a small  set  of  proprietary  ECL  chips. 
These  custom  gate  arrays  and  sequencers  enabled  Amdahl  to  implement  the 
370  instruction  set  directly  without  microcode. 

IBM  now  had  two  tiny  competitors  offering  instruction  set  compatible 
computers,  one  at  each  end  of  the  computer  line. 

Used  IBM  computers  in  the  hands  of  the  leasing  companies  with  PCM 
peripherals  were  impacting  the  middle  of  IBM's  370  line. 

Future  Systems  (FS)  was  conceived  by  a top  management  team  balanced 
between  development,  engineering,  finance,  marketing,  and  software. 

FS  would  not  be  constrained  by  previous  360  and  370  architecture  nor 
by  concerns  over  customer  migration  through  instruction  set  compati- 
bility. 

FS  would  be  the  new  generation  of  computer  architecture  that  would 
provide: 

. Wide  range  of  performance  (beyond  SO  MIPS). 

. Data  base  management  requirements. 

. Distributed  data  processing  needs. 

. Relative  ease  of  programming. 
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. Market  control  for  IBM's  peripherals  and  software  through 
integrated  file  adapters  and  OS  firmware. 

By  1976,  it  was  apparent  that  FS  was  in  trouble;  too  many  conflicting 
design  and  marketing  constraints.  To  have  a computer  family  that  was 
modular  and  expandable  from  .5  to  10  MIPS  as  well  as  to  provide 
design  hooks  to  move  controllers  into  internal  CPUs  became  mutually 
impossible  objectives. 

. The  3031,  2,  3 were  introduced  as  price/performance  and 
re-packaged  upgrades  of  the  370/158,  168. 

. Parts  of  FS  development  were  re-packaged  as  narrower  range 
product  family  groupings:  8100,  System/38,  E Series  (4300),  and 
H Series  (high  end  of  IBM's  line). 

In  1978,  Frank  Carey  of  IBM  explained  to  the  financial  community  that 
FS  was  too  ambitious  in  too  many  dimensions.  FS  would  not  be  a total 
research  write-off,  rather,  parts  of  FS  would  appear  in  new  products  in 
1979  and  1980. 

IBM's  top  management  is  beginning  to  realize  the  impact  microprocessors  can 
make  in  office  products  and  "medium  scale"  computers. 

The  semiconductor  companies  tend  to  price  their  products  on  a "manu- 
facturing cost-plus  basis."  Computer  companies  price  their  products  on 
a "value  to  the  customer"  basis.  If  the  customer's  current  costs  are  $X 
and  the  computer  system  only  costs  the  computer  company  $Y  to 
manufacture  and  support,  then  gross  profit  margin  is  $X  - Y.  That 
yields  a higher  margin  than  $Y  + y,  (cost  plus  small  profit).  Thus  value 
pricing  yields  higher  margins:  ($X  - Y)  compared  to  ($Y  + y).  IBM  feels 
that  as  the  semiconductor  companies  integrate  vertically  and  produce 
computer  subsystems,  their  pricing  mentality  will  result  in  significantly 
lower  prices  ($Y  + y)  and  profits  per  computer. 
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IBM  had  a choice:  1)  Stay  with  older  technology  (138,  148)  and  maintain 
high  profits  per  computer  but  lose  market  share,  or  2)  Impose  new 
manufacturing  technology,  new  LSI,  and  fewer  printed  circuit  boards 
upon  current  (not  new)  CPU  design.  The  resultant  lower  manufacturing 
costs  and  previously  amortized  software  allowed  IBM  to  reduce  prices 
by  75%.  This  discouraged  current  and  potential  competitors.  The  E 
Series  (4300)  was  born. 

How  could  IBM  try  to  maintain  old  levels  of  profitability  and  achieve  product 
differentiation?  Software. 

4300  announcements  on  January  30,  1979,  included: 

. DOS/VS  support  dropped:  January  1981. 

. Charging  for  more  program  products  and  getting  ten  times  more 
software  revenue. 

4300  will  use  primarily  DOS/VSE,  with  VM  as  the  bridge  to  beginning 
and  migrating  OS  users.  This  extension  is  facilitated  through  extra 
microcode  (see  INPUT'S  Vendor  Watch  report  "The  4300  Series: 
Computer  Systems  for  the  Future). 

MVS  will  be  the  surviving  large  computer  operating  system.  Extensions 
(MVSE)  will  be  implemented  in  microcode. 

The  clear  indication  from  the  8100,  System/38  and  4300  announcements 
is  that  IBM's  future  profits  will  shift  to  software. 

. The  8100  represents  old  technology,  (bipolar  based  CPU  design), 
but  totally  new  software. 

. The  4300  represents  the  same  technology  and  old  software  but 
with  microcode  assist  potential. 
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. System/38  represents  both  new  CPU  architecture  and  new 
comprehensive  software  (announced  as  well  as  potential). 

The  8100  was  a very  significant  announcement  for  users  because  IBM  blessed 
no-host  computing  and  set  the  precedent  for  charging  20  percent  to  33  percent 
for  software  as  a percentage  of  total  prices. 

The  8100  (Project  Orbit),  was  originally  conceived  as  a replacement  for 
3790  as  well  as  a vehicle  for  Satellite  Business  Systems  (SBS).  During 
the  summer  of  1978,  IBM's  top  management  pushed  the  8100  product 
manager  to  lower  his  pricing  algorithms,  increase  forecasted  volumes 
and  still  maintain  original  profitability  levels.  Expanding  the  software 
offerings  and  charging  more  for  them  permitted  abnormally  low  CPU 
and  memory  pricing. 

. Engineering  and  manufacturing  complained  that  they  could  not 
hit  the  required  memory  yields  and  manufacturing  costs  until 
mid  1981. 

. Software  development  programs  were  increased  and  planned 
delivery  dates  moved  forward.  These  extra  costs  were  written 
off  against  considerably  larger  forecasts. 

IBM's  SNA  had  always  presupposed  a central  370  until  the  8100 
announcement.  The  8100  design  permits  8 100's  to  communicate  with 
each  other  and  build  a distributed  data  processing  network  with  no  host 
(no  central  370).  Since  all  large  companies  already  have  central  data 
processing  facilities,  these  8100  users  will  initially  communicate  with 
centrally  located  files;  but  a new  DP  user  could  theoretically  get  along 
with  no  host,  if  he  had  a sufficiently  sophisticated  staff  to  manage  the 
software. 

. Datapoint,  Sycor,  Tandem  and  others  now  can  point  to  IBM's 
"distributed"  blessing. 
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. Large  companies  can  put  together  an  information  processing 
strategy  and  provide  for  migration  of  some  files  to  physically 
distributed  8100  locations. 

• Future  Systems,  FS,  would  have  been  a family  of  systems  similar  to  S/38. 
Some  of  the  design  concepts  and  goals  will  be  implemented  in  4300  and  H 
Series.  Although  FS  was  dropped,  pieces  are  in  all  the  new  systems.  IBM's 
strategies  are: 

Lower  hardware  pricing  through  parts  commonality  and  high  production 
volumes. 

Much  use  of  microcode  for  I/O  search/compares,  which  enhances 
performance  and  also  prevents  attachment  of  non-IBM  controllers  and 
peripherals. 

Lower  ratio  of  rental  to  purchase  prices  (now  32:1,  compared  to  the 
previous  40:1)  thus  encouraging  end  users  to  purchase,  not  lease. 

New  operating  systems  software  beyond  and  outside  the  public  domain. 

• The  best  clue  of  these  future  directions  is  the  System/38. 

IBM  has  made  the  S/38  package  relatively  hard  to  emulate.  All 
programmer  addressing  is  virtual.  All  I/O  control  and  logical-to- 
physical  address  translation  for  main  and  auxiliary  memory  is 
completely  under  control  of  the  service  control  program. 

No  assembler  language  will  be  released.  There  will  be  no  field  releases 
of:  principles  of  operations,  theory  of  operation,  microcode,  micro 
diagnostics,  or  fault  isolation  diagnostics  within  printed  circuit  boards. 
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If  someone  manages  to  reverse  engineer  the  S/38  and  its  peripheral 
controllers  and  disks,  the  software  to  run  it  will  still  cost  $500/month 
payable  to  IBM. 

IBM's  Data  Products  Division  regards  General  Systems  Division's  S/38  as 
a competitor  to  4331  and  8100.  But  in  fact  the  System/38  was  designed 
to  appeal  to  current  System/3  and  System/34  users  who  want  a logical 
upgrade.  IBM  will  keep  these  relatively  unsophisticated  customers  far 
away  from  any  knowledge  of  S/38  logics. 

• A possible  counter  strategy  for  PCM's  would  be  to  look  at  System/38  RPG-III 
and  DBMS  specifications,  and  then  write  compilers  and  DBMS  for  a "soft" 
target  computer  and  get  the  same  numeric  answers  from  programs. 

After  achieving  source  level  compatability,  the  "soft"  computer  may  be 
tuned  for  high  performance.  But  the  lower  manufacturing  cost 
advantage  will  still  be  IBM's. 

• The  same  general  procedure  will  be  used  on  DPD  machines  to  maintain  IBM's 
market  share. 

IBM  views  cache  memory  on  4300's  and  H series  as  the  main  preserve  of 
systems  residence.  The  high  cache  ratio  (95  percent)  is  largely  due  to 
the  frequency  of  supervisor  execution  relative  to  various  application 
codes.  If  appropriate  microcode  (extended  instructions)  can  be 
developed  to  handle  parts  of  the  operating  system,  it  will  be  migrated 
from  cache  to  write  control  store  to  further  lock  out  the  PCM's. 

IBM  will  soon  introduce  new  channel  interface  standards  that  are  two 
bytes  wide.  The  4300  already  has  some  integrated  file  adapters.  The 
fastest  growing  segment  of  the  business  is  now  communications  and 
terminals.  The  "old"  3704/5  communications  adapters  are  expensive 
and  clumsy.  IBM  may  adopt  special  communication  channels  (CC)  to 
accommodate  the  above.  These  new  CC's  will  likely  be  relatively 
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intelligent,  multiple  parallel  processors,  permitting  the  introduction  of 
a high  performance  relational  data  base. 

m Thus  the  stage  has  been  set  for  a new  generation  of  computers  as  different 
from  present  offerings  as  the  360  was  from  the  1401.  Will  the  software 
transition  also  be  as  dramatic? 


8.  SOFTWARE  REACTIONS 


• When  it  was  first  announced,  the  IBM  705  was  introduced  not  as  a computer, 
be.,  an  engineering  and  scientific  machine,  but  as  a "data  processing  machine." 
It  was  specifically  designed  for  commercial  processing  on  a large  scale,  and 
was  priced  at  a lofty  $6Q0/hour. 

© Smaller  businesses  were  also  able  to  enter  the  data  processing  ranks  in  the 
1950's  with  the  IBM  650,  a considerably  less  powerful,  but  more  affordable  unit 
that  was  priced  at  the  rate  of  $50/hour.  For  this  amount,  the  users  (mainly 
small  banking,  accounting,  and  insurance  establishments)  were  able  to 
construct  programs  of  up  to  2,000  instructions;  enough  to  go  beyond  the  simple 
payroll  and  accounting  problems  performed  on  the  older  electric  accounting 
machines,  sorters,  collators  and  tabulators. 

• "Systems  Software"  of  the  day  consisted  mainly  of  assemblers  such  as  SOAP 
(SHARE  Optimum  Assembly  Program),  which  not  only  handled  the  symbolic 
translation  of  mnemonic  programs  into  machine  language,  but  also  organized 
them  in  a way  that  accommodated  the  physical,  rotational  time  delays 
associated  with  the  magnetic  drum  on  which  the  programs  were  stored. 

© By  1959,  the  advent  of  the  transistor  made  possible  the  announcement  of  the 
new  IBM  7070  series  for  large  commercial  users. 
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Equally  significant  to  the  introduction  of  that  "second  generation" 
machine  was  the  1959  development  of  COBOL,  a COmmon  Business 
Oriented  Language."  The  realization  had  dawned  on  a few  people  that 
something  better  and  easier  to  use  than  symbolic  machine  language  was 
required  if  data  processing  was  to  fulfill  its  commercial  potential. 

Other  high  level  language  translators  and  compilers  also  began  to  appear  at 
this  time,  as  well  as  the  first  utility  programs:  standard  sorts,  merges,  file 
transfer  packages,  and  I/O  programs  that  could  be  used  in  conjunction  with 
user-written  application  programs. 

It  soon  became  apparent  thdt  there  was  a noticeably  different  operating 
characteristic  between  commercial  work  and  scientific  work.  Commercial 
work  was  "I/O  bound."  Slow  peripherals  made  it  impossible  to  get  enough  data 
into  memory  to  keep  the  CPU  busy. 

Small  memories,  combined  with  a widespread  failure  to  appreciate  the 
nature  of  channel  contention  problems,  contributed  to  the  delays. 
Users  who  installed  both  input  and  output  devices  on  the  same  channel 
wondered  why  their  programs  didn't  run  faster. 

IBM  decided  the  answer  was  to  develop  an  improved  "operating  system." 
This  would  allow  two  or  more  commercial  programs  to  occupy  the  CPU 
concurrently,  and  so  maximize  the  utilization  of  this  expensive  device. 
The  drive  to  consume  all  available  instruction  cycles  was  born. 

By  1963,  there  were  still  only  about  5%  of  commercial  programs  written  in 
COBOL,  and  the  almost  unanimous  choice  of  the  275  large  scale  IBM  users 
surveyed  as  to  the  most  important  software  characteristic  was  "ease  of  use." 
The  lone  exception  was  a preference  for  "speed  of  operation"  in  sorting 
programs. 

IBM's  "easy  to  use"  answer  was  OS,  which  came  replete  with  the  most 
complex,  artificial,  and  unforgiving  command  language  ever  invented:  JCL. 
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• What  OS  was  very  good  at,  however,  was  consuming  memory  and  instruction 
cycles.  An  analysis  of  the  raw  performance  potential  of  the  360/65  would 
indicate  that  it  could  have  replaced  1,000  of  the  Model  650  machines.  Fully 
50%  of  this  potential  was  consumed  by  OS. 

Additional  performance  degradation  factors  due  to  the  use  of  high  level 
languages,  emulation,  and  memory  starvation  brought  the  true  improve- 
ment ratio  down  from  1000:1  to  126:1  (see  INPUT'S  report  on  "New 
Hardware  Economics,"  June  1977). 

• The  same  trend  was  not  only  maintained  but  accelerated  with  the  introduction 
of  VS  on  the  370/ 1 68. 

Whereas  the  raw  power  rating  of  the  168  is  3,600  times  that  of  the  650, 
the  overhead  consumed  by  VS  amounts  to  70%  of  this  potential, 
reducing  the  true  improvement  ratio  to  432:1. 

• But  capability,  not  efficiency,  is  a better  measure  of  the  value  of  a system. 
The  new  operating  systems  and  other  systems  software  did  provide  large  scale 
users  with  a set  of  tools  for  multiplying  productivity,  both  of  the  equipment 
and  of  the  applications  that  were  produced  on  it.  The  bottom  line  of  the 
improvement  equation  is  still  the  amount  of  DP  power  that  can  be  delivered  to 
the  end  user. 

• The  ultimate  determinant  of  value  therefore  depends  largely  upon  the  quality 
of  the  man/machine  interface.  The  fewer  the  intermediary  translations  and 
barriers  between  the  end  user  and  the  data  he  needs,  the  more  likely  the 
information  he  receives  will  be  useful,  timely,  accurate,  and  comprehensive. 
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• These  are  system  factors  that  depend  as  much  on  the  organizational  environ- 
ment and  its  structural  characteristics  as  on  the  technological  properties  of 
the  hardware/software  combination.  No  software  system  designer  can  afford 
to  ignore  the  management  style  and  philosophy  of  the  organization  in  which 
the  system  will  be  operated.  We  must  therefore  look  at  the  history  of  the 
organizational  DP  environment. 


C.  ORGANIZATIONAL  ACCOMMODATION 


• Originally  the  exclusive  territory  of  the  corporate  comptroller  and  his  staff, 
the  "IBM  room"  was  a place  that  enticed  no  one  to  return  after  the  first 
curious  visit.  It  was  a noisy  place,  cluttered  with  machinery,  cards,  boards, 
and  wires.  The  only  possible  advantage  attached  to  it  was  that  it  might  be  the 
only  air  conditioned  spot  in  the  building. 

• As  users  began  to  discover  that  these  strange  machines  could  be  useful  for 
more  than  just  payroll  and  accounting,  new  corporate  organizational 
alignments  were  constructed  to  manage  the  valuable  data  processing  resource. 
New  computer  developments  coincided  with  new  discoveries  in  management 
science,  such  as  operations  research,  simulations,  PERT  and  other  manage- 
ment tools.  These  new  management  tools  and  new  computing  resources  each 
supported  the  other  during  a period  of  rapid  growth. 

• The  typical  growth  pattern  in  the  1960's  took  the  form  of  a separate  data 
processing  center  in  each  major  division  and  often  in  each  major  plant  location 
as  well.  There  was  a kind  of  contagious  enthusiasm  for  decentralization 
throughout  the  early  1960's  that  was  brought  to  a halt  five  or  six  years  later  by 
two  factors:  one  managerial  and  the  other  economic. 

• Managerial ly,  headquarters  were  experiencing  a need  for  much  greater 
quantities  of  information.  Planning  the  future  course  of  the  organization 
required  "Management  Information  Systems,"  and  every  forward-looking 
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company  hastened  to  construct  its  own  MIS.  But  the  usual  data  processing 
"cottage  industry"  structure  typically  could  not  support  a MIS.  Data  were  not 
comparable  between  divisions,  or  reporting  periods  were  not  synchronized,  or 
the  rapid  influx  of  supporting  staff  had  brought  in  hordes  of  inexperienced 
programmers  out  in  the  divisions  who  were  not  sophisticated  or  capable  enough 
of  developing  the  complex  central  programs  that  were  required. 

• At  the  same  time,  the  third  generation  IBM  360's  were  being  delivered.  They 
arrived  to  the  accompaniment  of  economic  realities  that  not  only  permitted 
but  demanded  multi-shift,  multi-program  operation  to  achieve  the  cost/benefit 
ratios  they  promised. 

The  pendulum  had  begun  its  swing  back  to  centralization  of  DP, 
reflecting  the  prevailing  centralization  philosophy  of  top  management. 

e The  effects  of  this  change  in  management  philosophy  were  traumatic  for  many 
EDP  departments.  Not  only  did  they  have  to  cope  with  the  technology 
conversion  from  second  generation  to  third  generation  hardware  and  software,  but 
DP  "card  shop"  supervisors  also  had  to  learn  to  manage  their  departments  in  a 
more  controlled  way. 

• The  discipline  of  operating  a profit  center  (or  in  most  cases,  a cost  center!) 
required  new  techniques  of  budgeting  control  and  management  that  rapidly 
separated  the  men  from  the  boys. 

Turnover  among  EDP  managers  became  an  occupational  hazard;  but 
with  the  hazard  came  the  opportunity  for  the  successful  EDP  depart- 
ment to  rise  to  middle  management  ranks,  rather  than  to  remain  solely 
a clerical  accounting  or  support  function. 


-32- 


© 1979  by  INPUT,  Palo  Alto,  CA  94303.  Reproduction  Prohibited. 


INP 


Strengthening  the  move  back  toward  centralization,  but  at  the  same  time 
aggravating  many  organizations'  hard  feeling  toward  data  processing  was  the 
subsequent  introduction  of  data  base  technology.  Seen  by  the  EDP  department 
as  a tool  for  improving  programmer  productivity,  it  appeared  to  the  end  user 
as  just  another  wedge  between  himself  and  the  information  he  needed. 

The  introduction  of  a data  base  concept  for  many  organizations  has  been  the 
final  step  which  causes  them  to  "give  up"  on  data  processing.  Data  base 
systems  caused  delays  and  frustrations,  confusion,  and  generally  increased  user 
charges.  But  those  organizations  who  have  gotten  over  the  initial  shock  find 
that  they  are  indeed  in  a position  to  implement  high  value,  integrated 
applications  such  as  materials  requirement  planning,  general  ledger,  and  order 
entry  all  working  together. 

These  types  of  online,  interactive  systems  largely  represent  the  present  state 
of  the  art.  Most  EDP  organizations  today  can  barely  keep  up  with  user 
demand  for  more  online  systems,  regardless  of  what  they  may  cost. 

Consequently  the  pendulum  has  begun  to  swing  again,  this  time  toward 
decentralization— but  with  a difference.  There  will  be  much  tighter  control 
exerted  this  time,  and  not  everything  will  be  decentralized.  Watchwords  are: 

Distributed  data  processing. 

Distributed  data  base. 

Off-loading  development  to  users. 

Giving  the  data  back  to  the  owners. 

These  topics  and  how  users  are  planning  for  them  will  be  discussed  in 
succeeding  chapters. 
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IV  RECENT  AND  CURRENT  EVENTS  - 
OPPORTUNITIES  AND  PROBLEMS 


IV  RECENT  AND  CURRENT  EVENTS  - OPPORTUNITIES  AND  PROBLEMS 


A.  DRIVING  FORCES 


I . CENTRALIZATION/DECENTRALIZATION 

• In  the  February  1979  report,  "Network  Implementation  Alternatives,"  INPUT 
pointed  out  the  benefits  of  centralization  of  EDP  into  one  or  a small  number 
of  major  processing  centers: 

Large  central  processors  have  greater  economy  of  scale  (i.e.,  a 3033  has 
1.8  times  the  price/performance  ratio  of  a 3031  or  a 370/158). 

Scarce  personnel  skills  can  be  used  more  effectively  (i.e.,  management 
planning,  systems  programming,  performance  measurement  and  tuning, 
communications,  etc.). 

Standards  can  be  more  easily  established  and  enforced,  both  for  systems 
and  for  networks. 

Cost  control  is  improved  because  better  information  is  available  to 
management  and  the  chain  of  command  is  shorter. 

Savings  on  peripherals  can  be  effected  through  better  resource  manage- 
ment. 
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Software  savings  can  be  achieved  through  the  use  of  centralized 
products  and  systems,  as  well  as  through  uniformity  of  procedures. 

Despite  these  benefits  of  centralization,  a strong  economic  and  managerial 
case  can  be  made  for  properly  decentralizing  and  or  distributing  certain 
functions  from  the  central  facility. 

Remaining  centralized  would  be: 

. Heavy  computation. 

. Transaction  processing  against  large  data  bases. 

. RJE  replacement  of  standalone  batch  systems  (if  processing 
capacity  is  available  and  real  costs  for  the  standalone  facilities 
can  be  eliminated). 

Decentralized  and/or  distributed  would  be: 

. Network  control  (front  end). 

. Scientific  timesharing. 

. Program  development  and  maintenance. 

. Simple  transaction  processing. 

. Collection,  editing,  and  display  of  data. 

. Control  of  terminals. 

. Sensing  and  control  devices. 

Real  cost  savings  through  decentralization  may  then  be  achieved  through: 
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Reduced  communications  costs. 


Reduced  central  processor  costs. 

• At  the  same  time,  intangible  (but  equally  important)  cost  savings  may  be 
realized  through: 

Improved  service  levels. 

Improved  functionality. 

Improved  competitive  positioning. 

• In  order  to  determine  whether  the  centralization/decentralization  pendulum  is 
indeed  swinging  toward  the  decentralization  side,  INPUT  compared  how  users 
ranked  their  companies  on  this  issue  in  connection  with  a study  on  a related 
topic  conducted  approximately  18  months  ago. 

Overall,  86%  of  the  I 13  respondents  interviewed  then, described  them- 
selves as  "strongly  centralized,"  but  anticipated  a decline  to  50% 
"strongly  centralized"  by  1983. 

• A similar  study  conducted  nine  months  ago  revealed  that  87%  of  the  40 
respondents  considered  their  companies  to  be  strongly  centralized  in  systems 
definition,  while  70%  had  a strongly  centralized  programming  function. 

• An  analysis  of  responses  to  this  study  shows  quite  a different  pattern,  as 
revealed  in  Exhibit  IV- 1 . 

Nine  of  the  26  respondents  (or  35%)  ranked  themselves  "very 
centralized"  generally. 

• On  the  other  side  of  the  coin,  six  respondents  described  the  EDP  function  as 
mostly  or  very  decentralized. 
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TOTAL  NUMBER  OF  RESPONDENTS  GIVING  THIS  RATING 


EXHIBIT  IV-1 


HOW  CENTRALIZED/DECENTRALIZED  IS  YOUR  COMPANY? 


VERY  MOSTLY  AVERAGE  MOSTLY  ‘ VERY 
DECENTRALIZED  CENTRALIZED 
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This  statistic  equalled  or  exceeded  the  "generally  decentralized" 
character  of  their  respective  companies. 

• Over  half  described  themselves  as  financially  very  centralized,  while  only  one- 
fourth  felt  they  were  managerially  centralized. 

• Thus,  comparing  the  total  number  of  "mostly"  or  "very  centralized"  ratings  to 
the  total  number  of  "mostly"  or  "very  decentralized"  ratings  produces  a 57% 
centralized,  20%  decentralized  distribution,  indicating  some  movement  toward 
decentralization  over  the  last  eighteen  months. 

The  EDP  function  shows  a slightly  stronger  trend  in  the  same  direction, 
with  a 52%  centralized,  22%  decentralized  position. 

• Respondent  comments  reinforce  this  conclusion.  The  driving  forces  toward 
decentralization  included  economics,  policy  decisions,  technology,  and  the 
need  to  capture  better  information  at  the  source. 

Fully  38%  of  the  respondents  expressed  the  opinion  that  their 
companies  would  be  even  more  decentralized  in  the  future. 

A few  representative  comments  are  shown  in  Exhibit  IV-2. 

• Of  course,  there  are  always  a few  companies  that  choose  to  run  contrary  to 
the  trend,  and  in  this  case  8%  of  the  respondents  expected  to  become  more 
centralized: 

To  achieve  economies  with  a higher  price/performance  central 
processor. 

To  reduce  payroll  by  centralizing  DP  staff. 

• Exhibit  IV-3  indicates  that  these  reponses  are  coming  from  companies  that 
generally  consider  themselves  to  be  among  their  industry's  leaders. 
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EXHIBIT  I V-2 


WHY  ARE  YOU  DECENTRALIZING? 


• |: ECONOMICS  IS  FORCING  THE  ISSUE,  AND  THE  TECHNOLOGY 
IS  BECOMING  AVAILABLE . " (CONSUMER  ELECTRONICS 
MANUFACTURER) 

• "DP  FUNCTIONS  WILL  BECOME  MORE  DECENTRALIZED  AS 
ACADEMIC  AND  ADMINISTRATIVE  FUNCTIONS  ARE 
SEPARATED „ 11  (STATE  UNIVERSITY) 

• WE  ARE  EXPERIENCING  A TREND  TO  DECENTRALIZATION 
IN  EDP  BECAUSE  HARDWARE  IS  BECOMING  AVAILABLE 

AT  A LOWER  COST."  (CONSUMER  PRODUCTS  MANUFACTURER) 

• "EDP  WILL  BE  MORE  DECENTRALIZED  BECAUSE  WE  WANT  EACH 
BANK  TO  HAVE  MORE  INDIVIDUAL  CAPABILITY." 
(CORRESPONDENT  BANK) 

• "OUR  CONSTITUENT  HOSPITALS  ARE  NOW  BEING  DECENTRAL- 
IZED BY  A MANAGEMENT  POLICY  DECISION." 

(MUNICIPAL  HOSPITAL  CHAIN) 

• "WITH  DISTRIBUTED  DATA  PROCESSING,  EACH  DEPARTMENT 
WILL  CONTROL  STS  OWN  SPENDING." 

(STEEL  MANUFACTURER) 
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GIVING  THIS  RATING 


EXHIBIT  IV- 3 


DOES  YOUR  COMPANY  USUALLY 
PLAY  AN  INDUSTRY  LEADERSHIP  ROLE? 


AMONG  TOP  AVERAGE 

THE  THIRD 

FIRST 


BOTTOM 

THIRD 
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Over  half  of  them  feel  that  they  are  at  least  in  the  top  third  of  their 

industry. 

Only  20%  feel  they  are  in  the  bottom  third. 

One  company,  for  example,  is  currently  working  on  a fully  automatic, 
computer  controlled  warehouse  that  it  expects  to  bring  on-line  in  1980. 

Another  company  is  integrating  all  its  manufacturing  applications  from 
order  entry  through  production  planning,  inventory,  purchasing,  manu- 
facturing, work  in  process,  and  shipping. 

IMPROVED  FUNCTIONALITY 

There  is  hardly  an  organization  today  that  does  not  have  at  least  one 
application  on-line.  Certainly  "on-line"  is  a very  common  watchword  when  DP 
managers  are  queried  about  issues  and  plans  for  the  near  future. 

The  sale  of  CRT  terminals  has  been  among  the  highest  subsectors  of  the 
industry,  expanding  at  the  rate  of  35-40%  per  year. 

Specialized  terminals,  such  as  the  IBM  3600  Financial  Terminal,  are  in 
high  demand. 

Respondents  to  this  study  who  were  asked  what  factors  caused  them  to  make 
changes  in  software  listed  improved  functionality  by  a two  to  one  ratio  over 
the  next  highest  factor,  as  shown  in  Exhibit  SV-4. 

Under  this  heading  are  included  many  of  the  popular  buzzwords  of  today? 
Electronic  mail. 

Office  of  the  future. 
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EXHIBIT  IV-4 


WHY  DO  YOU  MAKE  CHANCES  IN  SOFTWARE? 


IMPROVED  FUNCTIONS, 
USER  DEMAND 


REDUCED  COST, 
ECONOMIC  FACTORS 


NEW 

TECHNOLOGY 


GROWTH,  BUSINESS 
CHANGES 


EFFICIENCY, 

PERFORMANCE 


OBSOLESCENCE 


GOVERNMENT 

REGULATIONS 


EASE  OF  USE 


MEET  COMPETITION 


MISCELLANEOUS 


0 10  20  30  40 


PERCENTAGE  OF  TOTAL  MENTIONS 
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Word  processing. 


Management  workstations. 

Each  of  these  topics  will  be  discussed  later  in  more  detail,  but  it  is  interesting 
to  note  that  while  most  respondents  felt  these  functions  have  a medium  to 
high  likelihood  of  becoming  available  within  the  next  two  years,  very  few  of 
the  respondents  are  actively  working  on,  or  making,  plans  to  implement  these 
systems  at  their  own  companies  in  the  two  year  timeframe. 

In  fact,  every  one  of  these  areas  has  already  been  implemented 
somewhere,  at  least  on  a pilot  basis. 

REDUCED  COST 

Economic  factors  are  of  course  very  important  in  determining  whether  or  not 
to  replace  old  applications  or  develop  new  ones.  Users  are  frequently  required 
to  prepare  cost  justifications  for  new  data  processing  software,  particularly  if 
outside  software  packages  are  being  considered. 

Only  8%  of  respondents  to  this  study  said  that  cost  justifications  were 
not  always  required. 

However,  about  one-fourth  said  that  these  purchases  did  not  have  to  be 
specifically  identified  in  the  budget  in  order  to  obtain  them. 

A variety  of  justification  techniques  may  be  employed  in  making  the  decision 
whether  or  not  to  utilize  outside  software. 

These  techniques  varied  from  the  casual  to  the  exquisite,  with  most 
occupying  a reasonable  midrange. 

With  the  more  extensive  and  detailed  techniques,  one  may  wonder  whether  the 
cost  of  evaluation  and  justification  might  not  exceed  the  price  of  the  product. 
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Few  companies  place  a high  enough  dollar  threshhold  on  the  price  of 
packages  that  must  be  justified.  Many  insist  that  all  outside  software 
must  be  cost  justified,  regardless  of  price. 

The  highest  purchase  limit  that  was  found  to  be  within  the  DP 
manager's  discretion  was  $5,000,  well  below  the  cost  of  a single  DP 
employee  of  the  lowest  level. 

With  outside  software  packages  representing  one  of  the  most  cost- 
effective  productivity  improvements  available  (see  INPUT'S  February 
1979  report  on  "Performance  Improvement:  User  Techniques  and 

Experiences"),  it  is  hard  to  imagine  the  continued  value  of  this 
restrictive  practice. 

• Exhibit  IV-5  portrays  graphically  the  range  of  cost  justification  techniques 
that  are  in  use. 

Since  respondents  may  employ  more  than  one  technique,  the  percentage 
figures  are  calculated  on  the  basis  of  total  number  of  mentions,  rather 
than  total  number  of  respondents. 

RO!  and  improved  time  efficiency/capacity  are  very  different  in  the 
degree  of  formality  and  precision  each  represents.  Comments  from 
respondents  concerning  miscellaneous  techniques  also  reflect  a wide 
range  of  precision,  as  shown  in  Exhibit  1V-6. 

As  one  respondent  points  out,  it  is  often  hard  to  identify  the  true  cost 
saving  or  cost  avoidance  that  may  be  involved.  A careful  reading  of 
managerial  style  and  personality  may  be  as  important  as  the  dollars 
involved. 

• Replacement  personnel  cost,  while  still  receiving  17%  of  the  total  mentions,  is 
rapidly  disappearing  as  an  opportunity  to  justify  new  data  processing  appli- 
cations. As  many  users  have  found  out,  not  only  do  the  personnel  not 
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EXHIBIT  SV-5 


WHAT  COST  JUSTIFICATION  DO  YOU  USE 
TO  EVALUATE  OUTSIDE  SOFTWARE? 


DISCOUNTED  CASH  FLOW 


PERCENTAGE  OF  TOTAL  MENTIONS 
OF  COST  JUSTIFICATION  TECHNIQUES 
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MISCELLANEOUS  COST  JUSTIFICATION  TECHNIQUES 


• "DEGREE  OF  SERVICE  IMPROVEMENT." 

• "UNIT  QUANTITY  DISCOUNT." 

• "CHEAPER  TO  BUY  THAN  TO  BUILD." 

• "COST  AVOIDANCE." 

• "COST /BENEFIT  ANALYSIS." 

• "AMOUNT  OF  POTENTIAL  USAGE." 

• "MUST  RECOVER  COSTS  FROM  OTHER  PARTS  OF  THE 
BUDGET." 
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disappear  from  the  organization,  but  additional  personnel  are  often  required  to 
satisfy  the  needs  generated  by  the  new  applications. 

NEW  TECHNOLOGY/OBSOLESCENCE 

These  two  factors  are  discussed  together  because  they  often  represent  two 
sides  of  the  same  coin. 

Greater  storage  capacity,  improved  processing  speed,  new  control  devices, 
new  input/output  peripherals  all  create  opportunities  to  perform  functions  that 
were  not  feasible  previously. 

The  570  MB  disk  announced  by  IBM  in  connection  with  the  4300  will 
make  it  possible  to  keep  a total  of  almost  ten  gigabytes  of  data  on-line 
at  a rental  cost  of  $1,500  per  gigabyte. 

Unfortunately,  to  utilize  this  capacity  efficiently,  users  will  have  to 
reprogram  any  applications  that  do  not  use  fixed  block  mode  recording 
and  relative  addressing;  i.e.,  for  most  users,  100%  of  their  applications 
will  have  to  be  rewritten. 

On  the  other  side  of  the  coin,  DAM  and  ISAM  are  obsolete  as  far  as  the  new 
units  are  concerned.  Thus,  these  kinds  of  applications  will  have  to  be  not  only 
rewritten,  but  redesigned. 

Other  key  software  products  on  the  obsolete  or  nearly  obsolete  list 
include: 

. DOS/VS  (to  be  replaced  by  DOS/VSE,  not  compatible). 

. MVS  on  the  370  series  (still  alive  on  303X;  however,  will  likely  be 

replaced  on  large  4300  and  H-series  by  MVSE). 
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Needless  to  say,  the  increases  in  program  products  charges  and  the  establish- 
ment of  maintenance  fees  for  software  based  on  the  cost  of  the  CPU  also  have 
the  effect  of  squeezing  out  systems  software  that  is  useful,  but  less  frequently 
used. 

EFFICIENCY/PERFORMANCE 

Who  has  ever  implemented  IMS  correctly  the  first  time?  Some  experts  suggest 
that  managers  should  plan  to  throw  away  the  first  implementation  of  any  new 
system,  for  reasons  that  relate  not  only  to  the  inherrent  complexity  of  the 
system  design  process,  but  also  to  the  very  human  characteristic  of  wanting 
"just  a little  bit  more"  once  the  user  sees  what  the  new  system  can  do. 

When  asked  if  they  had  ever  experienced  performance  or  other  problems  with 
their  DBMS,  60%  of  the  respondents  to  this  study  replied  in  the  affirmative. 

Excessive  response  time  was  cited  specifically  by  50%,  while  the  other 
10%  listed  such  problems  as: 

. High  cost. 

. Limit  to  the  number  of  transactions  that  can  be  processed  at  one 
time. 

. Excessive  level  of  complexity. 

Only  one  user  in  the  10%  category  had  IMS  installed,  but  represented  in 
the  50%  problem  category  besides  users  of  IMS  were  users  of  TOTAL, 
ADABAS,  IDMS,  and  System  2000. 

Nevertheless,  all  of  the  users  had  been  able  in  some  way  to  compensate  for  the 
original  poor  response  time,  either  by  hardware  of  software  means. 
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Hardware  cures  consisted  in  one  case  of  adding  more  memory,  and  in 
the  other  of  switching  to  a higher  power  machine. 

Software  fixes  included: 

. Splitting  the  data  base. 

. Redesigning  codes. 

. Using  a different  DB  schema. 

. More  training  for  programmer/analysts. 

. Periodically  restoring  the  data  base. 

. Better  design  the  second  time  around. 

GROWTH/BUSINESS  CHANGES 

Not  mentioned  nearly  as  frequently  as  expected,  growth  and  changes  in  the 
nature  of  business  are  factors  that  always  require  extensive  software  changes. 

Whether  growth  occurs  within  a company's  main  line  of  business  or  from 
mergers  and  acquisitions  has  a great  influence  on  the  direction  new 
software  development  must  take. 

In  the  latter  case,  a complex  "foreign"  set  of  hardware,  software,  and 
operating  practices  may  come  as  part  of  the  merger  package.  To  make 
these  compatible  with  the  host  company's  counterpart  systems  may 
have  been  next  to  impossible  until  recently. 
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Now  that  VANs  (Value  Added  Networks),  USHS  (User  Site  Hardware 
Service),  and  a multitude  of  emulators  and  conversion  aids  are  widely 
available  , DP  departments  have  many  alternative  tools  to  help  with  the 
conversion  and  transition  process. 

• When  growth  occurs  within  a company's  own  line  of  business,  these  tools  may 
also  be  of  some  transitional  assistance. 

The  obvious  opportunity  to  "do  it  right  this  time"  may  be  seen  as  the 
major  benefit  of  what  otherwise  can  be  a very  hectic  experience. 

• But  most  critical  to  top  DP  management  should  be  the  opportunity  that  growth 
affords  to  participate  in  the  major  strategy  decisions  of  the  organization  by 
taking  advantage  of  today's  DP  technology. 

Contribution  to  the  bottom  line  of  the  company's  P&L  statement 
through  the  implementation  of  strategic  business  planning  systems  is 
many  more  times  more  valuable  than  improving  the  operating 
efficiency  of  almost  any  other  manufacturing  or  marketing  or  financial 
control  program.  This  is  where  the  true  return  on  investment  comes 
from,  and  this  is  where  the  corporate  DP  resources  should  be  directed. 

This  relationship  suggests  that  all  new  software  development  should  be 
subjected  not  to  a cost  analysis  (only),  but  to  a value  analysis.  (See 
INPUT'S  report  of  May  1979  on  "Planning:  A Methodology  For 

Protecting  Your  EDP  Investment.") 

DP  management  can  no  longer  defend  the  practice  that  was  so  common 
in  the  past,  and  still  is  being  widely  expressed  by  respondents  to  this 
study  as  a criterion  for  selection  of  software  areas  to  be  developed; 
namely,  that  every  user's  request  will  be  honored  if  he  has  the  budget  to 
pay  for  it. 
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7. 


REGULATION/MISCELLANEOUS  FACTORS 


• Named  frequently  by  respondents  in  the  regulated  industries  (banking  and 
finance,  insurance,  utilities,  transportation),  as  well  as  by  government  organ- 
izations themselves,  were  the  effects  that  changes  in  government  regulations 
have  on  the  development  and  maintenance  of  applications  software. 

Not  only  are  the  changes  complex,  often  contradictory,  and  usually 
"effective  immediately,"  they  also  are  as  stable  as  butter  on  a hot  day. 
Any  application  in  these  industries  that  is  not  designed  to  be  changed 
easily  will  soon  show  its  fragile  nature  by  breaking  down. 

• Companies  in  strongly  competitive  industries  such  as  banking  find  that  they 
must  rapidly  offer  the  same  services  as  other  competitors  or  suffer  the 
consequences  of  losing  market  share.  Software  changes  are  required. 

• A concern  for  security,  perhaps  impelled  by  the  company's  auditors,  may  result 
in  a mandate  to  revise,  or  totally  redesign,  extensive  software  systems. 

More  than  one  respondent  spoke  in  hushed  tones  of  having  to  redo 
critical  S 40 1 applications  because  there  was  no  way  to  trace  their 
functioning  any  more. 

B.  DEVELOPMENT  PRINCIPLES 


• Clearly  the  most  common  characteristic  of  data  processing  since  its  develop- 
ment 30  or  so  years  ago  has  been  its  susceptibility  to  change. 

« It  has  also  been  recognized  for  almost  as  long  that  the  way  to  minimize  the 
deleterious  effects  of  change  is  to  design  programs  and  systems  that  are 
meant  to  survive  and  accommodate  changes. 
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• Knowing  this  and  doing  it  are  two  quite  different  skills;  but  some  basic 
principles  apply.  A helpful  list  was  included  in  the  so-called  "SILT  Committee 
Report,"  published  in  1976. 

Solutions  must  minimize  the  percentage  of  total  software  in  a new 
application  that  is  new  software. 

Solutions  must  reduce  the  rate  at  which  the  results  of  programming 
efforts  are  rendered  obsolete. 

Solutions  must  broaden  the  usefulness  of  the  new  software  that  is 
generated. 

Solutions  must  significantly  reduce  the  present  requirements  for 
specialized  skills,  experience,  and  training  needed. 

Solutions  must  significantly  raise  the  acceptable  minimal  levels  of 
productivity  of  individual  software  developers. 

Solutions  must  materially  aid  in  overcoming  the  communication 
problems  associated  with  the  definition  of  applications  requirements. 

Solutions  must  eliminate,  or  at  least  drastically  reduce,  the  variability 
in  the  structural  design  of  an  application  that  is  introduced  by  different 
designers  and  implementors. 

• Characteristics  of  software  produced  according  to  these  principles  include  the 
following: 

That  if  will  exhibit  a high  level  of  standardization  in  its  own  structure 
and  at  its  interfaces. 

That  it  will  be  tolerant  and  forgiving  of  faults,  not  breaking  down  or 
behaving  unpredictably. 
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That  it  will  be  tutorial,  intuitively  understandable. 


. This  in  turn  implies  small  size  and  limited  (single,  local) 
functions  of  each  of  its  components. 

That  it  will  be  flexible  and  can  grow  with  experience  without  requiring 
a major  restructuring. 

That  it  will  be  reusable  (by  parametization  or  other  means). 

That  it  will  be  auditable. 

That  it  will  be  "closer"  to  the  end  user. 


C COMPATIBLE,  PORTABLE  SOFTWARE 


• Translating  these  principles  and  characteristics  into  tangible  objects  produces 
a requirement  for  compatible,  portable  software.  This  has  been  a design  goal 
since  COBOL  was  produced  as  the  COmmon  Business  Oriented  Language  that 
would  facilitate  the  transfer  of  programs  among  any  of  the  major  hardware 
systems:  IBM,  Univac,  Honeywell,  GE,  Burroughs,  or  whatever.  It  is  scarcely 
less  a goal  and  more  a reality  today  than  it  was  fifteen  years  ago. 

Emulators,  translators,  and  conversion  aids  do  make  it  possible  to  take 
some  systems  written  for  one  machine  and  make  them  work  after  a 
fashion  on  a different  machine.  But  this  achievement  sacrifices  the  use 
of  "extensions"  to  the  basic  language  subset  which  make  it  easier  or 
quicker  or  more  powerful  to  use. 

The  most  portable  software  is  usually  the  packages  offered  for  sale  by 
the  independent  software  vendors. 
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• By  restricting  the  number  of  options  to  a more  manageable  size,  it  is  possible 
to  develop  applications  which  can  run  on  the  various  models  of  a single 
hardware  vendor,  and  perhaps  a limited  number  of  other  machines  as  well. 

• Is  the  effort  worth  doing?  Only  a company's  own  particular  circumstances  can 
answer  that  question.  But  when  the  life  cost  of  a software  system  (including 
maintenance)  is  compared  to  the  original  development  cost  of  the  system 
(approximately  a 3:1  ratio),  it  would  seem  that  the  small  incremental 
investment  at  the  beginning  of  the  program  would  be  likely  to  be  repaid  many 
times  over. 

• The  temptation  to  break,  or  at  least  bend,  the  standards  "a  little  bit"  is  a 
strong  one.  Strong  arguments  can  always  be  brought  forward  to  rationalize 
saving  a minute  here  or  an  hour  there. 

That  is  why  the  standards  certification  and  quality  control  testing  of 
software  should  be  done  by  a group  for  whom  this  is  the  sole  loyalty  and 
responsibility.  Users  who  have  implemented  such  an  independent 

arrangement  find  that  their  production  failure  rate  falls  close  to  zero  in 
short  order. 


D.  TURNKEY  APPLICATIONS/SOFTWARE  PACKAGES 


• If  turnkey  applications  were  value  priced,  most  would  cost  considerably  more 
than  they  do  today.  Respondents  to  this  study  were  asked  their  impression  of 
software  pricing  practices.  The  results  are  shown  in  Exhibit  IV-7. 

Respondent  reaction  does  not  agree  with  the  above  assessment, 
claiming  by  a large  margin  that  purchased  software  is  correctly  priced 
or  somewhat  overpriced. 

Applications  software  is  described  more  generally  as  overpriced. 
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EXHIBIT  IV-7 


ARE  YOU  GETTING  GOOD  VALUE  FOR 
YOUR  PURCHASED  SOFTWARE  DOLLAR? 


SYSTEMS  SOFTWARE 


□ 

□ 


UTILITY  SOFTWARE 


APPLICATIONS  SOFTWARE 
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However,  in  evaluating  the  cost  of  outside  software,  few  respondents 
include  a value  for  opportunity  costs  incurred  if  they  had  to  develop  the 
application  themselves. 

Furthermore,  few  organizations  could  absorb  the  several  hundred  man 
year  effort  required  to  develop  large  projects  such  as  a generalized 
information  retrieval  package  or  a data  base  management  system. 

Thus,  respondents  were  reasonably  well  disposed  toward  turnkey  systems,  as 
shown  in  Exhibit  IV-8. 

A large  62%  were  in  favor  of  turnkey  systems,  while  none  considered 
them  a threat. 

However,  two  respondents  felt  strongly  that  turnkey  systems  were  not 
valuable.  Their  comments: 

. "Worthless!  Just  a money-making  idea  for  someone." 

. "Mirage,  there  is  no  such  thing  as  a turnkey  system." 

Respondent  comments  from  those  who  thought  turnkey  systems  are 
valuable  are  shown  in  Exhibit  IV-9. 

Respondents  were  also  asked  their  attitude  toward  software  packages  in 
general.  Results  are  shown  in  Exhibit  IV- 10. 

Definitions  used  for  this  question  are  as  follows: 

Systems  Operation  Products  function  during  application  program 
execution,  and  include: 

. Operating  systems. 
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EXHIBIT  IV- 8 


ARE  TURNKEY  SYSTEMS  AN  ADVANTAGE  OR  A THREAT? 


ADVANTAGE 


THREAT 


DEPENDS  ON 
SITUATION 


OTHER 


NO  COMMENT 


0 20  40  60  80 

PERCENTAGE  OF  RESPONDENTS 
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WHY  ARE  TURNKEY  SYSTEMS  AN  ADVANTAGE? 


• "COST  EFFECTIVE." 

• "QUICKER  IMPLEMENTATION,  BETTER  MAINTENANCE 
WHEN  REQUIRED." 

• "SOFTWARE  IS  ALREADY  DEVELOPED." 

• "SUPPORT.  ALSO  THE  SYSTEM  IS  AVAILABLE  QUICKER 
THAN  DOING  IT  YOURSELF." 

• "WOULD  REDUCE  THE  'BODY  COUNT'  - BUT  ONLY  IF 
IT  FIT  THE  NEEDS  OF  THE  ORGANIZATION." 

• "FASTER  IMPLEMENTATION,  LOWER  COST." 

• "MORE  CAPABILITIES." 

• "CAN  WORK  AT  THE  TRANSACTION,  NOT  APPLICATION 
LEVEL." 

• "HAVE  TESTED  SYSTEMS  TO  USE." 

® "GIVE  YOU  WHAT  YOU  WANT  WITH  A MINIMUM  OF  TIME 
SPENT  ON  DEVELOPMENT." 
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□ H 


EXHIBIT  IV-10 


WHAT  IS  YOUR  ATTITUDE  TOWARD  SOFTWARE  PACKAGES? 


SYSTEMS 

OPERATION 

PRODUCTS 


SYSTEMS 

UTILIZATION 

PRODUCTS 


SYSTEMS 

IMPLEMEN- 

TATION 

PRODUCTS 


APPLICATION 

SOFTWARE 

PRODUCTS 


0 5 10  1 5 20  25 

NUMBER  OF  RESPONDENTS 


PREFER 
CONSIDER 
WON'T /CAN'T  USE 
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Data  base  management  systems. 


. Communications  monitors. 

. Emulators. 

. Spoolers. 

. Related  products. 

Systems  Utilization  Products  are  used  primarily  by  operations 
personnel,  and  include: 

. Performance  measurement  tools. 

. Job  accounting  tools. 

. Computer  operations  scheduling  tools. 

. Utilities. 

. Related  products. 

Systems  Implementation  Products  are  used  primarily  by  programmers 
and  analysts,  and  include: 

. Language  interpreters  and  compilers. 

. Sort  programs. 

. Production  aids. 

. Data  dictionaries. 
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Report  writers. 


. Project  control  systems. 

. Program  library  management  systems. 

. Retrieval  systems. 

. Related  products. 

• Again,  the  majority  of  respondents  are  well-disposed  toward  the  use  of  outside 
software,  ranging  from  65%  who  would  consider  or  prefer  to  use  outside 
software  for  applications,  to  85%  who  would  consider  or  prefer  to  use  outside 
developed  DBMS,  communications  monitors,  etc. 

• A further  question  was  directed  as  to  the  form  in  which  these  software 
packages  were  most  useful: 

"Off-the-shelf"  (standardized,  no  customization). 

Parameter-driven  (semi-customized). 

Fully  customized. 

Available  as  a no-commitment  rental  from  a computer  services 

company. 

• The  responses  were  much  more  heavily  oriented  toward  standard,  "off-the- 
shelf"  packages  than  might  have  been  expected.  Results  are  shown  in  Exhibit 
IV- 1 I. 
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EXHIBIT  SV-11 


HO V/  SHOULD  SOFTWARE  PACKAGES  BE  SOLD? 


STANDARD  NO  CUSTOMIZATION 

SEMI-CUSTOMIZED 
FULLY  CUSTOMIZED 

COMPUTER  SERVICES 
NO  PREFERENCE 
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E, 


PERSONNEL  AND  TRAINING  REQUIREMENTS 


• Current  projections  are  that  there  will  be  about  twice  as  many  general  purpose 
computer  systems  in  the  U.S.  by  1980  as  there  were  in  1977.  If  each 
installation  requires  a minimum  of  one  EDP  professional  (programmer  or 
analyst),  there  will  be  at  least  a 25%  shortfall  of  trained  computer  profes- 
sionals by  the  end  of  1980;  and,  of  course,  the  average  requirement  is  higher 
than  one  professional  per  installation  right  now. 

• This  realization  has  already  dawned  on  many  of  the  respondents,  who  see  a 
glum  future  in  terms  of  the  availability  of  qualified  personnel. 

Exhibit  IV- 1 2 indicates  that  about  60%  of  the  companies  surveyed  are 
experiencing  a moderate-to-severe  shortage,  especially  of  experienced 
systems  analysts/programmers. 

Turnover  rate  in  these  companies  is  averaging  15-20%  a year,  but  as 
high  as  25%  in  some  companies. 

The  past  few  months  have  been  noticeably  worse  than  a year  ago,  with 
several  respondents  reporting  that  they  have  lost  more  staff  members 
already  in  the  first  4-5  months  of  1979  than  they  did  during  all  of  1978. 

• When  asked  whether  they  expected  the  personnel  situation  would  change,  only 
12%  thought  the  hiring  picture  would  improve  over  the  next  two  years  (see 
Exhibit  IV- 1 3). 

Half  thought  it  would  stay  the  same  as  it  is,  i.e.,  generally  more  jobs 
available  than  people  to  fill  them. 

Twelve  percent  thought  hiring  would  become  somewhat  more  difficult, 
and  the  remaining  26%  thought  it  would  be  much  harder  to  find 
qualified  EDP  professionals. 
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EXHIBIT  I V— 1 2 


ARE  YOU  EXPERIENCING  A PERSONNEL  SHORTAGE  NOW? 


SEVERE 


MODERATE 


SLIGHT 


NONE 
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EXHIBIT  I V — 1 3 


WHAT  WILL  HAPPEN-  TO  THE  PERSONNEL 
SHORTAGE  IN  TWO  YEARS? 


0 20  40  60  80  100 

PERCENTAGE  OF  RESPONDENTS 
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In  the  five-year  timeframe  (Exhibit  IV- 1 4),  the  prospect  was  seen  to  be 
marginally  better  overall,  mainly  because  respondents  will  have  had  to  find 
ways  to  cope  with  the  situation. 

Among  the  techniques  that  DP  managers  propose  to  use,  the  most  favored  is 
'Improved  Productivity  Through  Training  And/Or  Incentives,'  mentioned  by  half 
of  the  respondents  (see  Exhibit  IV- 1 5).  But  this  may  turn  out  to  be  a self- 
deluding  remedy. 

The  same  group  of  respondents  described  their  present  training  time  devoted 
to  programming  improvement  techniques  in  qualitative  terms  that  ranged  from 
'little'  to  'considerable,'  and  in  quantitative  terms  from  one  week  to  six 
months,  with  two  weeks  being  a common  value. 

Respondents  were  evenly  divided  as  to  whether  the  training  was 
voluntary  or  required. 

In-house  training  is  offered  by  85%  of  the  companies;  two-thirds  of  all 
the  respondents  supplement  this  training  or  depend  entirely  upon 
training  services  provided  by  outside  vendors  (including  IBM). 

But  one-fourth  of  the  respondents  reported  that  the  training  required  more 
time  than  originally  anticipated,  while  results  often  left  something  to  be 
desired. 

DP  managers  reported  budgeting  up  to  8%  of  their  personnel  resources 
for  training,  which  if  added  to  a 25%  shortfall  in  staff  availability  spells 
crisis  for  any  DP  department  that  experiences  it. 

Other  techniques  proposed  to  help  cope  with  personnel  shortages  include 
greater  use  of  packaged  software,  and  improved  productivity  through 
technology. 


-67- 

© 1979  by  INPUT,  Palo  Alto,  CA  94303.  Reproduction  Prohibited. 


INPUT 


EXHIBIT  I V—  1 4 


WHAT  WILL  HAPPEN  TO  THE 
PERSONNEL  SHORTAGE  IN  FIVE  YEARS? 


PERCENTAGE  OF  RESPONDENTS 
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EXHIBIT  IV-15 


WHAT  TECHNIQUES  WILL  YOU  USE  TO 
COPE  WITH  THE  PERSONNEL  SHORTAGE? 


PERCENTAGE  OF  RESPONDENTS 
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Again,  these  techniques  may  be  illusory  in  that  most  companies 
surveyed  already  make  extensive  use  of  efficiency-improving  systems 
software,  such  as  data  base  management  systems,  on-line  program 
development  aids,  and  generalized  information  retrieval  packages. 

Technology  improvements,  while  they  may  make  the  software  run 
faster  and  thereby  extend  for  a few  months  or  a year  the  time  at  which 
certain  applications  must  be  replaced,  generally  will  not  assist  greatly 
in  shortening  the  development  time  required  for  new  applications. 

• Thus  the  two  techniques  mentioned  least  frequently  are  the  ones  most  likely  to 
be  effective: 

Offload  development  to  the  end  users. 

Stretch  out  development  time. 

• The  latter,  extending  development  time,  is  a possible  response  but  not  really  a 
desirable  solution  to  the  personnel  shortage  problem.  But  assisting  (or 
requiring)  end  users  to  develop  their  own  applications  offers  many  attractive 
possibilities  and  advantages. 


F.  ROLE  OF  THE  USER 


• It  is  not  really  a new  concept  that  the  user  should  be  more  involved  in  systems 
development.  When  COBOL  was  first  introduced  in  the  early  60s,  it  was  to  be 
a nearly  natural  language  that  would  be  self-documenting,  easily  understood, 
and  able  to  be  used  by  almost  anyone  to  develop  programs.  No  comment  is 
necessary  as  to  the  'blue  sky'  quality  of  those  claims. 

• Seven  or  eight  years  later,  when  generalized  information  retrieval  packages 
became  widely  available,  the  proposal  again  was  made  that  these  were  tools 
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suitable  for  use  by  the  end  user  to  solve  his  own  problems.  Results  were 
generally  better  than  they  had  been  with  trying  to  convince  end  users  to  write 
their  own  COBOL  programs,  but  still  were  far  from  satisfactory  in  bringing 
computing  down  to  the  end  user  level. 

For  many  users  it  was  the  necessity  of  having  to  deal  with  IBM's  Job 
Control  Language  (JCL)  that  caused  their  downfall  rather  than 
difficulties  with  MARK  IV,  Easytrieve,  etc.;  but  the  net  result  was  the 
same.  The  end  user  still  did  not  have  very  direct  access  to  data 
processing  as  a tool— and  many  grew  even  more  wary  of  data  processing 
in  general. 

Some  of  these  attitudes  still  persist.  Respondents  were  asked  to  characterize 
the  typical  role  of  the  end  user  in  their  respective  companies,  and  the  results 
are  shown  in  Exhibit  IV- 1 6. 

One-third  of  the  companies  replied  that  the  user's  role  is  minimal, 
limited  solely  to  the  identification  of  a need  for  data  processing 
services  or  a revision  or  modification  of  existing  systems. 

Another  one-third  described  their  users  as  moderately  involved  during 
the  course  of  new  systems  development.  In  most  cases  this  involvement 
extended  to  periodic  reviews  with  the  end  users  on  questions  or  points 
of  clarification  that  arose  during  the  system  design  phase,  but  not  more 
than  that.  Frequently  the  reluctance  to  become  more  involved  was  on 
the  part  of  the  user,  not  on  the  part  of  the  DP  management. 

About  one-fifth  of  the  companies  described  a heavy,  continuous 
involvement  by  their  users  that  was,  however,  fairly  recent  in  nature. 
Users  had  not  yet  fully  adapted  themselves  to  this  role,  but  were  being 
urged  to  do  so  by  their  own  management  and  DP  management.  Many  of 
these  companies  had  also  dispersed  their  analysts  into  the  user  depart- 
ments, rather  than  remaining  centralized  under  the  DP  department. 
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EXHIBIT  I V—  1 6 


WHAT  IS  THE  USER’S  ROLE  IN  SOFTWARE  DEVELOPMENT? 


ACTIVE  PARTICIPANT 


INITIATE 

REQUEST 

ONLY 


PERCENT  OF  RESPONDENTS 
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Only  about  one-tenth  of  the  responding  companies  described  a role  for 
the  users  that  shared  fully  in  the  responsibility  for  new  systems 
development,  even  to  the  extent  of  assuming  an  active  role  on  the  EDP 
steering  committee. 

Are  these  roles  satisfactory  as  far  as  the  DP  management  is  concerned?  Just 
under  half  of  the  respondents  said  yes.  But  over  60%  said  their  users  would  be 
getting  more  involved  in  the  future.  Some  specific  comments  as  to  the 
expected  effects  of  this  greater  involvement  are  shown  in  Exhibit  IV- 1 7. 

In  order  to  become  more  involved,  users  will  need  more  training  than  they 
presently  receive. 

Only  two  respondents  said  that  training  for  users  is  required  in  their 
companies,  and  one  of  these  requires  it  only  for  learning  how  to  operate 
the  terminals,  not  for  systems  understanding  or  programming. 

Another  is  considering  mandatory  introductory  courses  for  everyone  at 
the  VP  level. 

All  other  respondents  said  training  for  users  is  voluntary,  not  required. 

Many  users  clearly  are  looking  to  become  more  involved  in  DP,  not  because  it 
is  'the  thing  to  do,'  but  because  they  have  genuine  needs  which  the  DP 
departments  are  not  able  to  fulfil!  in  the  foreseeable  future. 

DP  managers,  while  they  are  intellectually  aware  of  this  situation,  have  not 
yet  moved  definitely  toward  the  effective  distribution  of  DP  power  to  the  end 
users.  On-line  systems  will  help,  and  DDP  will  help;  but  will  the  help  arrive 
soon  enough  using  current  tools  and  standards  of  productivity? 


-73- 

© 1979  by  INPUT,  Palo  Alto,  CA  94303.  Reproduction  Prohibited. 


INPUT 


EXHIBIT  SV-17 


HOW  WILL  THE  USER'S  ROLE  CHANGE? 


• "USERS  WILL  GET  MORE  INVOLVED,  WRITE  THEIR  OWN 
SOFTWARE." 

• "USERS  DON'T  TAKE  ENOUGH  RESPONSIBILITY  NOW. 

THIS  SITUATION  WILL  IMPROVE  A LITTLE." 

• "USERS  WILL  BECOME  MORE  INVOLVED  AS  THEY  BECOME 
MORE  ACCUSTOMED  TO  COMPUTERS." 

• "USERS  WILL  BE  MORE  DP-ORIENTED,  MORE  SELF-SUFFICIENT. 
THERE  IS  NOT  ENOUGH  TIME  TO  PRODUCE  ALL  THE  REPORTS 
CENTRALLY  NOW." 

• "THEIR  INVOLVEMENT  WILL  BE  MUCH  HIGHER  FROM 
INCEPTION  THROUGH  TESTING.  THEY  WILL  USE  THE 
DP  DEPARTMENT  AS  A TOOL." 

• "IF  A SHARED  CORPORATE  DATA  RESOURCE  DEVELOPS, 

THE  USERS  MAY  BECOME  MORE  ACTIVE  (THAN  THEIR 
PRESENT  MODERATE-TO-HEAVY  INVOLVEMENT)." 

• "THERE  WILL  BE  DEVELOPMENT  OF  TOOLS  SO  THAT  THE 
USER  CAN  BYPASS  THE  EDP  DEPARTMENT." 

• "USERS  WANT  MORE  INVOLVEMENT  AND  WILL  BE  MORE 
INVOLVED." 
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G. 


TOOLS  AND  TECHNIQUES 


• A current  'hot  topic'  in  data  processing  publications  is  new  programming 
languages. 

The  Department  of  Defense  has  recently  given  the  go-ahead  to  the 
standard  use  of  a single  language  ('ADA')  for  all  military  applications, 
replacing  separate  languages  that  had  been  used  by  each  branch  of  the 
military  service. 

PASCAL  is  being  announced  for  many  of  the  personal  microcomputers. 
Some  of  these  are  designed  to  implement  the  language  directly,  while 
others  continue  to  employ  compilers  as  an  intermediate  step. 

FORTH  is  another  powerful  microcomputer  (and  minicomputer) 
language  that  differs  radically  from  most  conventinal  languages  in  that 
it  consists  of  a combined  operating  system  and  programming  language 
that  stores  and  operates  upon  a series  of  definitions  that  have  been 
established  by  the  user. 

'C'  is  a structured  language  that  was  developed  at  Bell  Laboratories 
specifically  to  support  the  structured  programming  constructs 
(sequence,  do-while,  if-then-else).  It  too  is  available  for  both  mini- 
computers and  microcomputers. 

• These  languages  have  not  yet  penetrated  the  mainstream  of  data  processing. 
Respondents  to  this  study  are  typical  of  most  large  DP  installations  in  the 
programming  languages  they  employ,  as  shown  in  Exhibit  IV- 1 8. 

• COBOL  is  still  the  predominant  language  in  most  shops.  Respondents  were 
asked  to  characterize  the  percentage  of  their  applications  by  the  language  in 
which  they  have  been  written. 
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EXHIBIT  SV-18 

WHAT  LANGUAGES  ARE  YOU  CURRENTLY  USING? 


COBOL 
(n  = 22) 


ASSEMBLY 
(n  = 19) 


PL/1 
(n  = 10) 


FORTRAN 
(n  = 8) 


MARK  IV 
(n  = 4) 


MISCELLANEOUS 
(n  = 9) 


a = MEDIAN 


= MEAN 


PERCENTAGE  RANGE  OF  APPLICATIONS 
USING  THIS  LANGUAGE 
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On  the  average  (for  respondents  who  use  it  at  all),  67%  of  the 
applications  are  written  in  COBOL.  But  the  respondent  individual 
characteristics  are  such  that  if  a shop  uses  COBOL  for  any  applications, 
it  is  likely  that  most  applications  will  be  written  in  this  language. 

Thus  the  median  for  the  use  of  COBOL  is  75%,  which  means  that  half  of 
the  companies  surveyed  use  COBOL  for  three-fourths  or  more  of  their 
applications. 

The  next  most  popular  language  is  ASSEMBLY,  particularly  for  on-line  or 
performance  dependent  programs. 

Up  to  95%  of  all  applications  in  a given  company  may  be  written  in 
ASSEMBLY  language,  but  the  average  for  all  respondents  who  use  it  is 
28%,  and  half  of  the  companies  use  it  for  15%  or  less  of  their 
applications. 

FORTRAN  and  PL/ 1 are  both  popular  with  certain  companies,  although  neither 
language  is  used  for  all  of  the  applications  in  these  companies. 

On  the  average  of  all  respondents  who  use  it,  PL/ 1 is  used  for  27%  of 
the  applications  and  FORTRAN  for  18%. 

But  half  the  companies  use  PL/ 1 for  10%  or  less  of  their  applications, 
while  FORTRAN  is  used  for  20-50%. 

MARK  IV  is  the  only  other  'language'  that  was  mentioned  by  more  than  one 
respondent,  and  the  four  respondents  who  cited  its  use  say  that  up  to  20%  of 
all  their  applications  use  this  language. 

Two  languages  often  used  on  minicomputers  were  mentioned,  and  they  are 
BASIC  (used  for  80%  of  all  applications  by  this  respondent)  and  the  IMAGE 
package  available  on  Hewlett-Packard  hardware,  and  used  for  10%  of  all 
applications  by  this  respondent. 
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Respondents  were  also  asked  to  characterize  their  use  of  structured 
techniques  for  existing  applications  as  well  as  new  applications  under  develop- 
ment. There  is  now  a well-established  trend  to  use  structured  techniques,  at 
least  among  organizations  of  the  size  interviewed  for  this  study. 

Exhibit  IV- 1 9 shows  that  about  one-third  of  the  companies  have  seen  at 
least  a token  penetration  of  structured  techniques  into  existing 
applications,  with  almost  another  third  expressing  that  a sizable  portion 
(6-25%)  of  existing  applications  fall  into  this  category. 

Plans  and  objectives  are  even  more  ambitious,  with  many  respondents 
targeting  the  100%  level  of  new  applications  to  use  these  techniques. 

A variety  of  techniques  are  employed  by  most  users,  with  top-down 
design  being  mentioned  specifically  most  frequently.  A selective, 
pragmatic  approach  is  most  popular;  but  this  raises  the  question 
whether  the  organizations  are  reaping  the  full  effect  of  these 
synergistic  techniques  (see  INPUT’S  February  1979  report  on 
"Performance  Improvement:  User  Techniques  And  Experiences"). 

When  the  respondents  were  questioned  as  to  the  value  of  these  techniques, 
their  responses  were  quite  cautious,  supporting  the  inference  that  the 
techniques  are  being  implemented  informally  (see  Exhibit  IV-20). 

Sixty  percent  of  the  responses  described  the  techniques  as  'Useful  In 
Certain  Circumstances,'  while  only  20-25%  were  enthusiastic  enough  to 
call  them  'Great  Improvement.' 

Improvements  that  have  actually  been  seen  are  described  in  Exhibit  IV-21. 
Their  tenor  is  a qualified  approval,  and  maybe  that  is  all  that  can  be  expected. 
The  payoff  from  structured  techniques  is  long-term,  in  the  form  of  reduced 
need  for  maintenance,  and  easier  maintenance  when  it  is  required. 
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□ □ 


EXHIBIT  IV-19 


WHAT  PERCENTAGE  OF  YOUR  APPLICATIONS 
USE  STRUCTURED  TECHNIQUES? 


NONE 

I- 5% 
6-10% 

II- 25% 
26-50% 

51-89% 


90-99% 

100% 

DON'T  KNOW, 
INDEFINITE 


EXISTING  APPLICATIONS 
NEW  APPLICATIONS 
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EXHIBIT  IV-20 


HOW  VALUABLE  ARE  STRUCTURED  TECHNIQUES? 
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WHAT  IMPROVEMENTS  HAVE  YOU  SEEN 
FROM  THE  USE  OF  STRUCTURED  TECHNIQUES? 


MORE  RELIABLE  SOFTWARE  (5  RESPONDENTS). 

EASIER  MAINTENANCE  (5  RESPONDENTS). 

ON-TSME  DEVELOPMENT  (2  RESPONDENTS). 

BETTER  MATCH  TO  SPECIFICATIONS  (3  RESPONDENTS). 

"NONE,  ST  DEPENDS  MORE  ON  THE  PERSON  THAN  THE 
TECHNIQUE. " 

"100%  IMPROVEMENT  IN  ALL  AREAS." 

"TOO  EARLY  TO  TELL."  (5  RESPONDENTS) 

"25-30%  BETTER  RELIABILITY  AND  MAINTENANCE, 
SIGNIFICANTLY  BETTER  MATCH  TO  SPECIFICATIONS, 
BUT  DOES  TAKE  LONGER  TO  DO  ST  THIS  WAY." 

"RELIABILITY  AND  AVAILABILITY  ARE  IMPROVED,  BUT 
CAN'T  SAY  HOW  MUCH." 

"EASIER  DIAGNOSTICS." 

"NO  TREMENDOUS  SUCCESS  STORIES." 
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A number  of  respondents  have  been  using  the  techniques  long  enough  to 
notice  these  results. 

• Another  technique  which  has  produced  sizable  returns  in  programmer  produc- 
tivity is  the  use  of  some  form  of  on-line  program  development  aid. 

• All  of  the  respondents  use  an  on-line  program  development  tool,  of  which  the 
most  frequently  mentioned  is  TSO  (see  Exhibit  IV-22). 

U.S.  figures  also  support  the  approximate  7:1  ratio  of  TSO  over 
ROSCOE,  the  next  most  widely  used  product  nationally. 

CMS,  WYLBER,  and  the  in-house  products  used  by  the  other  respon- 
dents, together  with  ROSCOE,  seemed  to  produce  higher  levels  of 
satisfaction  than  TSO  did.  The  most  frequently  voiced  problem  raised 
about  TSO  is  its  enormous  appetite  for  resources. 

• Sample  comments  from  TSO  users  are: 

"TSO  could  be  using  up  more  computer  resources  than  we  are  willing  to 
pay  - it  eats  up  60%  of  the  mainframe." 

"Our  programmers  did  not  become  as  involved  as  we  thought  they  would 
because  we  did  not  purchase  enough  terminals.  This  is  not  the  fault  of 
TSO." 

"Don't  know  how  we  got  along  without  it,  but  it  is  still  expensive.  We 
did  a benchmark  based  on  the  number  of  turnarounds,  and  found  much 
improvement." 

"We  expected  25%  improvement,  but  actually  got  40-50%." 

• Thus  most  shops  are  satisfied  that  this  technique  has  been  worthwhile. 
Nineteen  of  twenty-six  respondents  described  the  results  as  equal  or  better  to 
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EXHIBIT  SV-22 


WHAT  ON-LINE  PROGRAM  DEVELOPMENT  TOOL  DO  YOU  USE? 


TSO 


CMS 


WYLBUR 


ROSCOE 


SN-HOUSE, 

OTHER 


NUMBER  OF  MENTIONS 
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what  they  had  expected,  while  only  two  felt  that  the  results  were  worse  (see 
Exhibit  IV-23). 

One  of  the  worse  results  was  felt  to  be  a tendency  to  sloppy,  'on-the- 
fly'  program  development  compared  to  previous  pencil  and  paper 
techniques. 

Most  respondents  have  been  using  on-line  program  development  aids  for  3 or 
more  years,  and  some  as  long  as  7-8  years. 

Those  who  have  been  using  it  longer  tended  to  be  more  satisfied  than 
the  newer  users,  who  are  still  sensitive  about  what  they  perceive  as  its 
high  cost.  But  the  recent  reduction  in  memory  prices  by  IBM  should 
attract  new  users,  who  may  be  more  willing  to  spend  $75,000  for  an 
additional  MB  of  memory. 

Data  Base  Management  Systems  are  also  in  widespread  use,  and  have  been  for 
3-4  years  for  most  of  these  respondents.  The  systems  that  they  have  in  use 
are  shown  in  Exhibit  1V-24. 

These  statistics  reflect  closely  the  national  distribution  of  DBMS,  with 
IMS  somewhat  more  than  twice  as  frequently  used  as  TOTAL. 

IDMS,  ADABAS,  and  System  2000  are  all  approximately  equal  behind 
the  other  two  products. 

Several  respondents  reported  using  two  or  more  competing  data  base 
management  systems,  each  for  a different  type  of  application. 

Fifteen  percent  of  the  respondents  are  not  now  using  a DBMS,  nor  do 
they  have  any  plans  to  do  so  in  the  near  future. 
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EXHIBIT  IV-23 


HAVE  THE  RESULTS  OF  SWITCHING  TO  ON-LINE 
PROGRAM  DEVELOPMENT  BEEN  AS  YOU  EXPECTED? 


BETTER 


AS  EXPECTED 


WORSE 


NO  OPINION 


NUMBER  OF  RESPONDENTS 
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EXHIBIT  1V-24 


WHAT  DBMS  ARE  YOU  USING? 


SMS 

TOTAL 

SDMS 

ADABAS 

SYSTEM  2000 

IMAGE 

FOCUS 

IN-HOUSE 

NONE 


NUMBER  OF  MENTIONS 
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The  number  of  separate  data  bases  in  use  at  each  company  was  difficult  for 
many  respondents  to  answer;  but  the  number  ranged  from  2 to  over  200,  and 
the  total  combined  size  from  3.5  megabytes  to  over  40  gigabytes. 

When  asked  if  there  would  be  any  advantage  to  combining  some  or  all  of  these 
separate  data  bases,  36%  of  the  respondents  replied  with  an  emphatic  "No!" 
(see  Exhibit  IV-25). 

Reasons  for  not  combining  them  generally  related  to  the  impracticality  of 
such  an  endeavor,  due  to  ownership,  back-up,  and  performance  problems. 

Those  respondents  who  felt  that  combining  data  bases  would  have  some 
advantages  cited  the  reasons  shown  in  Exhibit  IV-26. 

Performance  problems  were  cited  by  64%  of  the  respondents,  and  not  only  by 
those  who  are  using  IMS  (see  Exhibit  IV-27). 

Nevertheless,  46%  felt  that  they  would  eventually  require  a distributed  data 
base,  as  shown  in  Exhibit  SV-28. 

Another  15%  were  currently  undecided,  but  think  there  might  be  such  a 
need  sometime  in  the  future. 

Estimates  of  how  soon  this  type  of  facility  might  be  required  were  relatively 
imminent. 

Twenty  percent  of  the  respondents  feel  the  need  exists  now,  or  will 
exist  within  the  next  two  years  (see  Exhibit  IV-29).  Thus  these 
respondents  should  be  actively  engaged  in  planning  the  implementation 
of  these  systems. 

Another  20%  see  the  need  arising  after  the  two-year  period,  but  still 
within  the  foreseeable  future. 
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EXHIBIT  IV-25 


WOULD  THERE  BE  ANY  ADVANTAGE 
TO  COMBINING  YOUR  DATA  BASES? 


MAYBE 


PERCENT  RESPONDENTS 
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EXHIBIT  IV-26 


WHAT  ADVANTAGE  WOULD  THERE  BE 
TO  COMBINING  YOUR  DATA  BASES? 


• "LESS  SEPARATE  MAINTENANCE  FACTORS,  WOULD 
ELIMINATE  ERRORS  OF  OMISSION  IN  UPDATING  THE 
DATA  BASE." 

• THEORETICAL,  NOT  PRACTICAL." 

• "WOULD  ELIMINATE  SOME  REDUNDANT  DATA." 

• "WOULD  PROVIDE  CONTINUITY  AND  A SINGLE  INTERFACE." 

• "SHARING  OF  DATA." 

• "INCREASED  FLEXIBILITY  WHEN  ACCESSING  DATA  IN 
A SPECIFIC  APPLICATION  REQUIREMENT  (i.e. , TO 
CREATE  NEW  LOGIC  FLOWS)." 

• "THERE  MIGHT  BE  AN  ADVANTAGE  TO  SHARING 
INFORMATION  BY  DIFFERENT  DIVISIONS,  BUT  THIS 
IS  NOT  GENERALLY  REQUIRED." 

• "BETTER  AD  HOC  RETRIEVAL." 

• "LOGICALLY  ONLY,  NOT  PHYSICALLY." 
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EXHIBIT  IV-27 


HAVE  YOU  EXPERIENCED  PERFORMANCE 
OR  OTHER  PROBLEMS  WITH  YOUR  DBMS? 


USERS  OF 


IMS 

TOTAL 
IDMS 
ADABAS 
SYSTEM  2000 


USERS  OF 
IMS 

TOTAL 

IDMS 

ADABAS 


PERCENTAGE  RESPONDENTS 
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EXHIBIT  IV-28 


WILL  YOU  NEED  A DISTRIBUTED  DATA  BASE? 


PERCENTAGE  OF  RESPONDENTS 
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EXHIBIT  IV-29 


HOW  SOON  WILL  YOU  REQUIRE  A DISTRIBUTED  DATA  BASE? 


NUMBER  OF  RESPONDENTS 
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A final  20%  do  not  have  a clear  fix  on  how  soon  the  need  might  arise. 


These  figures  should  be  compared  to  the  statistics  for  distributed  data 
processing,  shown  in  Exhibit  IV-30. 

Twenty-three  percent  of  the  respondents  say  they  have  distributed  data 
processing  now. 

Implementations  primarily  use  the  main  host/star  network  configu- 
ration, although  a few  respondents  favor  a loosely  coupled,  standalone 
minicomputer  configuration. 

It  is  plausible  that  most  of  these  respondents  who  already  have  had  some 
experience  with  DDP  may  plan  to  upgrade  to  a distributed  data  base 
configuration  within  the  next  two  years,  based  on  the  assumption  that  they 
have  accumulated  the  necessary  technical  expertise  and  sophistication  to  do 
most  of  the  software  implementation  themselves. 

It  is  less  plausible  that  the  second  20%,  who  see  their  needs  for 
distributed  data  base  arising  in  the  2-5  year  time  frame,  will  have 
gained  an  equivalent  level  of  DDP  experience  when  they  do  not  expect 
to  have  their  DDP  systems  even  operating  until  I,  2,  or  3 years  from 
now. 

But  the  commercial  software  developers  may  come  to  their  rescue.  A group 
of  16  leading  commercial  software  companies  were  asked  how  likely  they  felt 
certain  new  software  products  would  be  available  in  the  two-year  and  five- 
year  periods. 

Their  responses  on  the  subject  of  distributed  data  base  software  are 
shown  in  Exhibit  IV-31. 

Responses  were  weighted  on  a 3:2:1  ratio  corresponding  to  a high: 
medium:  low  rating  of  likelihood  by  the  respondent. 
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EXHIBIT  IV- 30 


DO  YOU  HAVE  DISTRIBUTED  DATA  PROCESSING? 


CONSIDERING  IT 


PERCENT  OF  RESPONDENTS 
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EXHIBIT  IV- 31 


LIKELY  AVAILABILITY  OF 
DISTRIBUTED  DATA  BASE  MANAGEMENT  SYSTEMS 


IN  TWO 


IN  FIVE 


STANDARD  SCORE  (SEE  TEXT) 


VENDOR  RATING 
HIGH 
MEDIUM 
LOW 
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The  summary  of  responses  was  then  further  normalized  to  produce  a 
maximum  score  of  100  in  the  case  where  there  is  unanimous  agreement 
that  an  event  is  highly  likely  to  occur. 

Using  this  rationale,  the  software  vendor  consensus  shows  a reasonably 
good  likelihood  of  distributed  data  base  software  being  available  within 
two  years,  and  a very  high  probability  that  it  will  be  available  within 
five  years. 

• Another  alternative  solution  to  the  distributed  data  base  problem  is  to  use  a 

User  Site  Hardware  Service  (see  INPUT'S  Vendor  Watch  Report  of  January 
S979  on  "User  Site  Hardware  From  Computer  Services  Vendors:  A New 

Alternative  For  EDP  Managers").  Respondents  were  asked  whether  they  would 
consider  such  a service  (see  Exhibit  IV-32). 

As  may  be  expected  from  the  newness  of  such  an  alternative,  58%  of 
the  respondents  were  not  familiar  with  it  or  had  no  definite  opinion  one 
way  or  the  other. 

Fifteen  percent  thought  the  proposal  had  some  merit,  and  would 

consider  it. 

Twenty-seven  percent  felt  that  it  would  be  too  expensive,  or  that  they 
preferred  to  keep  control  of  DP  in-house. 

• Respondents  were  then  asked  the  rationale  that  they  had  employed  in  choosing 
their  DDP  configuration  (see  Exhibit  iV-33). 

Only  two  characteristics  stood  out  above  the  others  in  their  frequency 
of  mention: 

. Compatible  with  existing  installation. 

. Cost  effective  solution  to  the  problem. 
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EXHIBIT  IV- 32 


/ 


WOULD  YOU  CONSIDER  A USER  SITE  HARDWARE  SERVICE? 


YES 


PERCENT  OF  RESPONSES 
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EXHIBIT  IV- 33 


WHAT  CRITERIA  WILL  (BID)  YOU  USE  TO 
SELECT  YOUR  DDR  CONFIGURATION? 


NUMBER  OF  MENTIONS 
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Other  responses  were  evenly  divided  between: 


Hardware  already  in  place. 

Easy  to  use. 

Proven  in  similar  situation. 

Software  already  exists. 

Miscellaneous  other  factors. 

What  are  the  real  reasons,  then  for  DP  managers  to  expect  distributed  data 
bases  just  over  the  horizon? 

Distributed  data  bases  do  not  necessarily  provide  easier  or  better  access  to 
data.  In  specific  cases  they  may  be  more  cost-effective  (for  reduced 
communications  costs),  more  reliable  (because  smaller,  more  redundancy  in 
the  system,  closer  to  the  owner),  better  maintained  (for  the  same  set  of 
reasons).  But  they  may  also  be  none  of  these. 

The  truth  is  that  we  do  not  know  enough  about  our  present,  much  less  our 
future,  need  for  and  cost  of  data,  including  the  lost  opportunity  costs  of  not 
having  the  data. 

The  assumption  is  that  the  first  set  of  circumstances  described  above  holds 
true,  similar  to  the  biological  model  on  which  it  is  based. 

But  there  will  always  be  a need  for  certain  data  to  be  evaluated  and  acted  on 
centrally,  no  matter  how  it  may  be  made  available. 

Thus  we  have  come  full  circle  back  to  the  organizational  question  of 
centralization  versus  decentralization. 
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• DP  managers  who  are  not  sensitive  to  these  underlying  currents  (including  the 
psychological  currents)  may  find  that  their  users  are  engaged  in  an  end  run 
around  the  DP  department,  because  the  technological  opportunities  are  open 
and  waiting  for  the  new  breed  of  computer-familiar,  business  system  trained 
managers  to  'do  it  themselves.' 

• On  the  other  hand,  the  technological  opportunities  are  there  for  the  adept  DP 
manager  to  move  into  a whole  new  level  of  influence  on  the  strategic  course 
of  the  organization,  by  being  ready  to  turn  the  data  processing  resource  into  a 
corporate  data  resource. 
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V FUTURE  DIRECTIONS 


V 


FUTURE  DIRECTIONS 


• Productivity  is  the  issue  of  the  day.  The  cumulative  effects  of  vastly 
increased  computing  power,  growing  user  demand  for  more  immediate  access 
to  information,  rapidly  changing  business  conditions  and  government 
regulations,  combined  with  a growing  shortage  of  experienced,  qualified  EDP 
personnel,  make  it  mandatory  for  the  DP  manager  to  adopt  new  standards  of 
productivity  and  performance  for  his  department. 

• But  productivity  in  data  processing  is  an  elusive  term  to  define.  The  real 
standard  should  be  the  value  added  to  the  organization  by  the  correct, 
adequate,  timely  furnishing  of  information  resources  to  the  decision-makers, 
instead  of  the  much  less  global  measures  of  lines  of  code  per  day  or  cost  per 
hour  of  processing  time. 

Productivity  is  not  measured  in  any  real  sense  in  many  DP  organi- 
zations. But  the  implicit  productivity  (or  lack  of  it)  still  shows  up  in 
the  bottom  line  of  the  corporation. 

• The  software  development  process  has  recently  been  recognized  as  a major 
contributing  factor  to  the  overall  productivity  of  the  DP  organization.  Its 
impact  is  felt  two  ways: 

In  its  effectiveness. 

In  its  efficiency. 
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• These  should  be  complementary,  not  mutually  exclusive  productivity  goals. 
But  where  choices  can  be  made,  the  effectiveness  goal  generally  offers  a much 
higher  rate  of  return  than  does  the  efficiency  goal. 

• Previous  chapters  have  identified  the  history,  trend,  principles,  and  status  of 
software  development  to  this  point  in  time.  This  chapter  describes  and 
assesses  the  major  new  developments  that  are  expected  to  become  available  or 
widespread  within  the  next  five  years. 

• These  expected  developments  are  categorized  under  the  same  two  headings, 
those  relating  or  contributing  primarily  to  increased  effectiveness,  and  those 
relating  or  contributing  primarily  to  increased  efficiency. 

• In  some  cases  the  line  dividing  effectiveness  and  efficiency  had  to  be  decided 
arbitrarily,  because  the  new  development  not  only  does  something  useful  in  a 
less  costly  way,  but  also  makes  it  possible  to  do  something  additional  that 
could  not  be  done  before. 

A.  CURRENT  INVESTIGATIONS  - EFFECTIVENESS  AIDS 


I . RELATIONAL  DATA  BASE 

• The  primary  purpose  of  a relational  data  base  is  to  assign  to  the  system  all 
responsibility  for  mapping  the  conceptual  representation  of  data  to  its  physical 
storage  location.  Thus  the  programmer  will  be  freed  from  the  last  vestige  of 
concern  about  the  physical  structure  and  sequence  of  data,  and  can  concen- 
trate entirely  on  their  logical  and  conceptual  values. 

Since  1970,  the  IBM  Research  Laboratory  at  San  Jose  has  had  under 
development  a relational  data  base  known  as  'System  R.' 
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In  addition,  other  investigators  have  been  pursuing  relational  models 
such  as  INGRES,  which  is  implemented  in  the  'C'  language  in  conjunc- 
tion with  the  UNIX  operating  system  on  PDP-11  hardware  at  the 
University  of  California  at  Berkeley,  and  RISS,  which  is  available  from 
Forest  Hospital  in  Des  Plaines,  Illinois.  RISS  has  also  been  implemented 
on  PDP-I  I hardware  under  the  RSTS-I  I operating  system. 

For  further  details  on  the  relational  data  base  concept,  see  INPUT'S 
August  1978  report  on  "Data  Base  Software:  An  Evaluation  Of  Current 
Products  And  Future  Directions." 

There  is  a continuing  debate  between  supporters  of  the  relational  data  base 
concept  and  the  data-structure-set  or  CODASYL  model  represented  presently 
by  IDMS  and  IDS.  This  report  will  not  evaluate  the  merits  of  that  debate.  The 
key  questions  in  the  minds  of  many  large-scale  DBMS  users  are  whether  IBM 
will  be  able  to  make  'System  R'  deliver  reasonable  performance  on  large  (10 
gigabyte)  data  bases,  whether  its  subsequent  introduction  will  signal  the  end  of 
support  for  IMS,  and  whether  there  will  be  any  reasonable  migration  path  from 
IMS  to  RDB. 

Both  large-scale  users  and  large  software  vendors  were  surveyed  for  this 
report  to  determine  their  estimates  of  the  likelihood  and  rapidity  of  various 
software  innovations  becoming  commercially  available. 

Normalized  scores  were  assigned  to  their  responses  in  such  a way  that 
unanimous  agreement  on  a high  likelihood  of  a certain  event  occurring 
would  produce  a 'perfect'  score  of  100. 

Their  responses  to  the  question  of  whether  a relational  data  base  would 
become  available  produced  a medium  score  of  52  from  the  users  and  a high 
score  of  68  from  the  vendors  in  the  two-year  timeframe,  as  shown  in  Exhibit 

V-l. 
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EXHIBIT  V-1 


LIKELY  AVAILABILITY  AND  VALUE 
OF  RELATIONAL  DATA  BASE 


USER 

VENDOR 

ooooi: 

> ' 

RATING 

joooc 

HIGH 

E3 

MEDIUM 

- □ 

LOW 

- 104- 

© 1979  by  INPUT,  Palo  Alto,  CA  J4303.  Reproduction  Prohibited. 


100 


Both  estimates  grew  somewhat  overall  in  the  five-year  span,  but  more 
important  is  that  both  showed  a doubling  within  the  high  probability 
component  of  the  estimate. 

INPUT  considers  it  very  likely  that  a relational  data  base  product  for  large 
scale  users  (though  not  the  very  largest  users)  will  be  announced  in  conjunction 
with  the  "H"  Series  announcements  in  the  first  quarter  of  next  year. 

'System  R'  is  undergoing  extensive  beta  tests  presently. 

A relational  data  base  capability  (though  not  announced  as  such)  is  built 
into  the  System/38  architecture. 

The  new  570  MB  disk  and  its  associated  controller  unit  provide 
"multiple  data  access  paths"  which  could  provide  simultaneous  access  to 
4MB  of  data. 

Microprocessor  prices  have  reached  the  point  in  the  cost  curve  where  it 
is  conceivable  to  produce  a disk  with  one  microprocessor  per  track  to 
select  data  by  its  fit  to  a search  mask,  thus  offering  content- 
addressable  storage. 

However,  INPUT  does  not  believe  the  new  RDB  will  be  proposed  as  a 
replacement  for  IMS,  but  rather  as  a selectively  suitable  alternative  for  some 
new  development  applications. 

The  order  of  magnitude  performance  step  necessary  to  go  from  I 
gigabyte  to  1 0 gigabytes  of  storage  has  not  yet  been  solved. 

Users,  however,  correctly  rate  the  introduction  of  a relational  data  base  as 
quite  useful,  giving  it  a total  rating  of  58  points. 

The  high  level  of  interest  further  supports  this  rating;  only  15%  of  the 
user  respondents  were  unfamiliar  with  a relational  data  base. 
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NON-PROCEDURAL  LANGUAGES 


Languages  such  as  COBOL,  FORTRAN,  PL/ 1,  BASIC,  and  most  of  the  other 
common  high  level  languages  are  'procedural'  languages.  That  is,  they  provide 
a means  to  instruct  the  computer  how  to  perform  a certain  manipulation  of 
data  to  produce  the  results  we  are  seeking. 

A non-procedural  language  allows  the  programmer  (or  preferable  even  a naive, 
first  time  user)  to  tell  the  computer  what  results  we  are  seeking,  and  let  it 
determine  how  to  do  it. 

Key  to  the  success  of  a non-procedural  language  is  the  decoupling  of  data  from 
processing,  so  that  any  changes  to  the  data  attributes  (such  as  from  binary  to 
decimal,  or  from  8 digits  to  10  digits)  will  not  require  changes  to  the 
processing  program. 

Instead,  the  data  attributes  are  stored  in  a separate  data  dictionary,  or 
with  the  data  themselves. 

There  may  still  be  some  procedural  aspects  to  the  non-procedural  languages, 
for  it  will  still  be  necessary  to  establish  the  basic  processing  definitions  that 
produce  certain  processing  results.  But  these  basic  definitions  can  then  be 
named  and  nested  to  any  degree  of  complexity,  with  each  conceptual  level 
forming  a higher  level  building  block. 

The  availability  of  a relational  data  base  meets  very  well  the  criterion  for 
data  independence,  and  the  use  of  an  RDB  with  a non-procedural  language  is  a 
natural,  but  not  essentia!  step. 

Users  and  vendors  presumably  recognize  this  natural  relationship,  for  they 
rated  the  likelihood  of  a non-procedural  language  almost  identically  with  the 
rating  of  an  RDB,  both  in  the  two-year  and  five-year  periods  (see  Exhibit  V- 2). 

Vendors  in  both  cases  are  more  certain  that  such  products  will  appear. 
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EXHIBIT  V-  2 
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Again,  the  real  question  is  not  whether  such  products  are  possible,  for  they 
already  exist  and  have  proven  to  be  very  useful  in  certain  circumstances. 

RAMIS,  NOMAD,  and  Mark  IV  all  meet  some  of  the  criteria  for  a non- 
procedural language,  although  each  approaches  the  problem  in  a 
different  way. 

Most  users  are  more  interested  in  whether  IBM  will  introduce  such  a product, 
and  whether  it  will  have  better  performance  characteristics  than  the  other 
three  products. 

It  is  true  that  RAMIS,  NOMAD,  and  Mark  IV  can  consume  large  amounts  of 
computer  resources.  But  against  this  disadvantage  must  be  set  the 
advantages: 

Development  time  is  cut  from  days  to  hours,  or  months  to  days. 

Products  can  be  used  by  relatively  unskilled  personnel,  often  by  the  end 
user  himself. 

Costs  of  computer  resources  are  dropping  rapidly,  while  costs  of 
programmer-written  software  development  are  rising. 

Thus,  even  at  the  present  time,  the  usefulness  of  one  of  the  non-procedural 
languages  listed  above  can  provide  a productivity  improvement  worth  many 
times  its  cost  if  applied  in  a selective  manner  to  applications  for  which  it  is 
suited. 

IBM's  entry  into  the  field  appears  to  be  premised  on  two  products: 
Query-By-Example. 

SEQUEL  (Structured  English  Query  Language),  now  called  SQL. 
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• Of  the  two,  Query-By-Example  gives  the  naive  user  a broader,  more  compre- 
hensive frame  of  reference  by  displaying  a table  on  the  CRT  screen  that 
indicates  which  relationships  have  been  pre-identified. 

It  then  becomes  a simple  matter  to  handle  even  complicated  queries  by 
"filling  in  the  blanks,"  because  there  is  no  required  sequence  in  which 
the  tables  must  be  completed,  as  there  is  in  specifying  a query  in  a one- 
dimensional language. 

QBE  was  developed  to  be  used  in  conjunction  with  a relational  data 
base,  but  has  been  demonstrated  to  be  effective  also  with  a hierarchical 
data  base,  such  as  IMS,  and  is  claimed  to  work  with  a network  model  as 
well.  Performance  remains  a problem  for  "backward"  (bottom-up) 
searches,  however. 

• SQL  also  provides  an  easy  to  use  query  structure  that  uses  English-like 
grammer  and  vocabulary,  for  example: 

SELECT  NAME, 

FROM  EMPL, 

WHERE  DEPT  = "shipping" 

will  produce  a list  of  all  employees  who  work  in  the  shipping  department. 

Functions  such  as  COUNT,  MAX,  SUM,  AVG  can  be  included  by  simply 
specifying  these  terms  in  the  query. 

Control  breaks  are  provided  by  specifying  GROUP  BY  in  the  retrieval 
request. 

Exits  are  provided  to  programs  written  in  other  languages  for 
processing  that  is  too  complex  or  unwieldy  to  perform  directly  in  SQL. 
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Some  form  of  SQL  will  soon  be  announced  by  IBM,  either  as  a standalone 
language  or  as  language  extensions  to  COBOL  and  PL/ 1 , or  both.  Performance 
of  the  product  will  be  in  the  same  ballpark  with  IMS,  neither  better  nor  worse, 
as  long  as  the  requests  are  compiled  to  optimize  the  retrieval  paths. 

However,  SQL  will  be  much  easier  to  use  than  IMS,  particularly  for  the 
first-time  or  infrequent  user. 

WORD  PROCESSING  LINKED  TO  DATA  PROCESSING 

In  companies  where  word  processing  functions  have  already  been  consolidated 
into  organizational  entities,  there  is  beginning  to  be  some  thought  given  to 
merging  the  DP  function  and  the  word  processing  function  into  a sort  of  local 
information  resource. 

However,  most  companies  treat  word  processing  and  data  processing,  both 
organizationally  and  from  a policy  standpoint  in  very  different  ways. 

The  former  is  generally  left  to  the  discretion  of  the  department 
manager,  while  the  latter  is  highly  procedural i zed,  formally  budgeted, 
and  centrally  controlled. 

DP  managers  have  traditionally  been  reluctant  to  get  involved  with 
word  processing  activities,  except  insofar  as  they  involve  text  proces- 
sing software,  such  as  ATMS  or  STAIRS  on  the  mainframe,  and  run  like 
any  other  user  application. 

But  word  processing  technological  capabilities  have  advanced  very  rapidly  in 
the  last  three  to  five  years,  both  for  standalone  and  shared  logic  models.  For 
smaller  branches  of  large  corporations  as  well  as  for  any  applications  that  use 
text  processing  extensively,  multifunction  equipment  is  beginning  to  look 
extremely  attractive. 

Growth  is  taking  place  in  both  directions: 
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From  minis  and  even  microcomputers  that  now  offer  word  processing 
software. 

From  word  processing  systems  that  already  offer  communications  and 
are  beginning  to  offer  some  built-in  data  processing  capabilities. 

• The  use  of  a word  processing  station  as  an  I/O  terminal  appears  to  be  a natural 
extension.  It  is  a device  that  is  oriented  to  a specialized  kind  of  data  entry, 
but  can  be  operated  by  individuals  with  fairly  generalized  skills  and  only  a 
little  direct  training. 

Perhaps  the  major  technical  difference  between  the  word  processing 
station  and  a typical  "dumb"  CRT  terminal  is  the  block  oriented 
communication  format  of  the  word  processing  station,  compared  to  the 
character  oriented  format  of  the  dumb  terminal. 

• One  problem  is  that  the  embedded  control  characters  of  the  word  processor 
data  require  specialized  code  translations  and  message  reformatting  to  be 
performed  either  under  software  or  firmware  emulation  for  every  transmis- 
sion. Thus,  efficiency  is  reduced  far  below  the  level  that  could  be  obtained 
with  ordinary  DP  peripherals. 

This  is  one  of  the  biggest  drawbacks  with  current  word  processing 
"multifunction"  devices.  It  has  restricted  their  usefulness  to  particular 
circumstances,  rather  than  to  a broad  general  range  of  applications. 

Value  in  these  circumstances  is  more  a matter  of  convenience  than  of 
economies. 

• The  other  alternative,  in  which  basically  DP  oriented  gear  (minicomputers  and 
microcomputers)  take  on  the  ability  to  perform  word  processing  functions, 
suffers  from  induced  inefficiencies  in  the  operator's  performance. 
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The  word  processing  software  is  "kludgey,”  utilizing  artificial  combi- 
nations of  control  codes  to  perform  such  text  formating  functions  as 
paragraph  indentation,  tabulation,  capitalization,  underscoring,  and  the 
like. 

Single  purpose  word  processors  use  specific  typewriter  control  keys  for 
these  functions. 

Another  disadvantage  is  that  word  processing  output  delivered  to  a dot- 
matrix printer  is  rarely  of  satisfactory  quality  for  documents  that  must 
be  sent  outside  the  company. 

• Thus,  neither  alternative  (WP/DP  or  DP/WP)  would  be  likely  to  make  much 
headway  if  the  only  advantage  were  the  possible  economic  benefit  of  a 
multifunction  machine.  But  the  greatest  advantage  to  linking  word  processing 
to  data  processing  comes  from  those  situations  which  demand  some  ability  to 
revise  or  reformat  narrative  text,  as  well  as  to  retrieve  data  from  files  or  to 
perform  business  calculations. 

Preparation  of  engineering  or  contract  specifications,  procedure 
manuals,  software  documentation,  inventory  records,  professional 
billing,  and  certainly  the  link  to  electronic  mail,  are  all  possible 
applications  that  require  both  word  processing  and  data  processing 
functions  to  be  performed. 

• Respondents  gave  the  highest  utility  rating  to  word  processing  systems  linked 
with  data  processing  systems,  and  were  well  ahead  of  the  vendors  in  their 
estimates  of  how  soon  such  systems  might  be  available,  as  shown  in  Exhibit  V- 
3. 

DP  managers  believe  that  these  systems  will  be  widely  available 
commercially  within  two  years,  assigning  this  likelihood  a total  of  83 
points  out  of  a possible  100. 
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EXHIBIT  V - 3 


LIKELY  AVAILABILITY  AND  VALUE  OF 
WORD  PROCESSING  LINKED  WITH  DATA  PROCESSING 
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Major  software  vendors  judged  it  less  likely,  assigning  it  a total  of  only 
55  points. 

The  same  pattern  holds  true  in  the  five  year  time  period,  with  DP 
managers'  estimates  reaching  the  88  point  level,  while  software  vendors 
lagged  behind  at  75  points. 

• Since  some  of  this  equipment  and  capability  already  exists,  the  projections 
should  be  interpreted  as  an  indication  of  the  market  demand  for  such  systems 
outstripping  their  availability. 

On  the  other  hand,  even  though  several  of  the  software  vendors  now 
have  text  processing  packages  available  and  have  indicated  that  they 
will  be  making  improvements  and  extensions  to  these  packages,  the  real 
market  demand  is  likely  to  come  from  the  smaller  organizations  and 
smaller  organizational  units  which  have  traditionally  not  been 
approached  by  these  vendors. 

• INPUT  believes  that  this  is  an  area  of  great  ferment  and  confusion  that  will 
take  a couple  of  years  to  shake  out.  There  is  nevertheless  a substantial  risk 
for  the  DP  manager  who  does  not  keep  his  finger  on  his  own  organization's 
administrative  and  managerial  pulse. 

The  potential  for  integrating  word  processing  and  data  processing  into  a 
comprehensive  information  network  resource  can  only  be  captured  if 
coordinated  from  the  beginning  as  a compatible,  coherent  system. 

The  sudden  presence  of  myriads  of  small,  competing  word  proces- 
sing/data processing  systems  operating  at  the  local  level  but  demanding 
access  to  the  corporation's  main  data  banks  suggests  the  chaotic  scene 
the  complacent  DP  manager  may  otherwise  have  to  confront. 
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ELECTRONIC  MAIL 


"Electronic  mail"  is  a catch-all  term  that  means  different  things  to  different 
people: 

Telex  or  TWX. 

A network  of  communicating  word  processors. 

Facsimile  equipment  operating  over  voice  lines. 

A message  switching,  computerized  network,  either  public  or  private. 

Each  of  these  alternatives  exists  today  and  several  have  been  around  for  many 
years.  But  electronic  mail  is  being  discussed  and  to  some  extent  implemented 
at  a rate  far  exceeding  its  previous  history. 

Message  switching  systems  that  are  computer  driven  are  thought  by  many  to 
be  the  most  likely  foundation  for  electronic  mail  systems  and  indeed  offer 
many  advantages  not  possessed  by  the  other  three  alternatives.  But  the 
message-switching  system  has  its  own  set  of  disadvantages. 

Among  the  positive  features  of  a message-switching  system  are: 

It  is  asynchronous  (in  concept,  although  it  may  use  a synchronous 
protocol)  and  therefore  can  interface  with  a wide  variety  of  networks 
and  terminals,  as  well  as  with  other  message-switching  systems. 

It  is  the  most  flexible  in  the  message  time  and  priority  characteristics 
it  can  handle. 

It  can  provide  a high  degree  of  security,  although  this  characteristic  is 
not  inherrent  to  the  system  and  must  be  specifically  designed  and 
activated. 
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Simultaneous  or  staggered  transmission  to  many  recipients  is  possible 
from  a single  initiation. 

Messages  can  be  stored  and  accessed  at  later  times,  or  can  undergo 
further  processing  directly  upon  receipt. 

Systems  can  be  designed  for  use  by  unskilled  and  occasional  operators, 
including  the  end  user,  but  again  this  is  not  an  inherent  (or  even 
typical)  characteristic. 

Against  these  advantages  must  be  considered: 

The  very  high  initial  cost  of  such  systems. 

Communications  costs  which  are  low  on  a per  message  basis,  but  high  in 
the  aggregate,  and  subject  to  rapid  growth  based  on  popularity  of  the 
system. 

The  necessity  to  develop  and  maintain  a complex  set  of  highly  technical 
software,  or  to  depend  upon  a public  network  which  does  not  yet  exist 
in  all  the  locations  (especially  semi-rural  locations)  a company  may 
need  to  access. 

The  psychological  barrier  of  managers  who  have  an  aversion  to  utilizing 
a keyboard  themselves  can  be  formidable. 

Respondents  to  this  study  have  a high  expectation  that  electronic  mail  in  some 
viable  form  will  be  commercially  available  within  two  years  and  they  feel  its 
usefulness  would  be  high,  as  shown  in  Exhibit  V-4. 

Vendors  are  less  sure  that  electronic  mail  will  be  a reality  within  two 
years,  but  generally  agree  with  the  users  that  it  will  definitely  happen 
within  five  years. 
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EXHIBIT  V-4 


LIKELY  AVAILABILITY  AND  VALUE 
OF  ELECTRONIC  MAIL 
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• The  prototype  for  electronic  mail  is  the  ARPA-Net  "electronic  mailbox," 
available  primarily  to  military  organizations  and  to  the  academic  and  research 
community. 

Users  of  this  system  have  found  that  it  has  increased  their  personal 
productivity,  particularly  in  replacing  and/or  scheduling  face-to-face 
meetings  and  in  replacing  voice  telephone  calls. 

• Users  at  Citibank  have  been  able  to  access  an  electronic  mail  system  in 
conjunction  with  Citibank's  management  workstation. 

This  system  has  been  modified  considerably  since  its  first  introduction 
and  offers  word  processing,  filing,  and  appointment  calendar  capa- 
bilities in  addition  to  electronic  mail. 

• Digital  Equipment  Corporation  has  installed  an  electronic  mail  system  that  to 
date  has  been  used  only  in-house,  but  which  may  be  made  available 
commercially  as  well. 

Software  for  the  system  is  commercially  available  now,  and  was 
developed  by  Computer  Corporation  of  America  in  Cambridge, 
Massachusetts,  which  also  developed  the  DATACOMPUTER  data 
management  system  for  ARPA-Net,  as  well  as  the  Model  204  DBMS. 

CCA  also  offers  the  system  on  a timesharing  basis  for  a basic  charge  of 
$60/month  per  user,  which  offers  an  inexpensive  way  for  interested 
users  to  try  the  system  before  buying  it. 

Purchase  price  for  the  software  ranges  from  $150,000-250,000. 
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IBM  is  involved  in  electronic  mail  in  Europe,  although  not  yet  in  the  U.S. 
Current  implementations  are  for  IBM  in-house  use  only  in  Britain  and  France, 
and  utilize  the  IBM  3750  PABX  (available  only  in  European  countries) 
connected  to  MT/ST  word  processors  on  the  terminal  end,  which  are  then 
polled  during  off  hours  by  a central  CPU. 

IBM  World  Trade  Europe-Middle  East  is  encouraging  independent 
software  houses  to  develop  commercial  packages  using  the  Series/ 1 
mini  as  the  controller. 

However,  the  IBM  PABX  uses  technology  which  is  not  as  advanced  as 
that  offered  by  other  companies  in  the  U.S.  and  will  not  be  introduced 
here  for  that  reason. 

INPUT  believes  that  despite  the  regulatory  hassle  between  the  post  office  and 
the  common  carriers  which  will  not  be  soon  resolved,  electronic  mail  is  a 
viable  reality  for  in-house  use  today. 

Current  implementations  use  PDP/II  hardware,  but  that  is  not  a 
problem  for  many  companies.  Wang  and  other  minicomputer  vendors 
have  also  announced  electronic  mail  software  for  their  machines. 

Psychological  barriers  will  be  overcome  by  gentle  exposure  as  these 
mini-based  systems  become  more  widespread. 

Cost  savings  will  be  derived  from  the  improved  effectiveness  side  of 
the  ledger  and  appear  to  be  in  the  5%  range  figured  on  the  value  of  a 
manager's  time. 

INTEGRATED  OFFICE  SYSTEMS/MANAGEMENT  WORKSTATIONS 

Despite  the  achievements  of  data  processing  over  the  past  20-30  years  in 
automating  many  business  operations,  the  office  remains  an  overly  labor- 
intensive  and  often  ineffective  environment. 
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The  challenges  presented  by  the  opportunity  to  automate  these  functions  fall 
not  only  to  the  DP  manager.  In  many  cases,  it  is  not  even  dear  to  whom  they 
are  presented  because  they  cut  across  previously  defined  spheres  of  influence 
and  areas  of  responsibility. 

This  uncertainty  is  reflected  in  the  DP  managers'  responses  to  this  study  who 
felt  that  the  integrated  office  had  a less  than  even  chance  of  becoming  a 
reality  within  two  years,  as  shown  in  Exhibit  V-5. 

This  probability  Increased  only  to  50  points  In  the  five-year  time  frame, 
but  with  a larger  proportion  of  that  rating  being  made  up  of  "high"  and 
"medium"  probability  estimates. 

Software  vendors  are  more  optimistic,  but  still  reach  only  51  points  in  the 
two-year  period. 

Their  estimate  reaches  71  points  within  five  years. 

Ratings  for  the  likelihood  of  management  workstations,  a related  but  less 
ambitious  undertaking,  were  almost  identical,  as  shown  in  Exhibit  V-6. 

Neither  concept  was  felt  to  be  useful  from  the  respondents'  points  of  view, 
achieving  total  scores  of  only  30  of  a possible  100  points. 

INPUT  believes  this  rating  is  more  indicative  of  the  emotional 
responses  such  topics  provoke,  rather  than  of  the  simple  gains  or  losses 
in  efficiency  that  installation  of  the  devices  may  achieve. 

To  the  extent  that  only  technology  is  required,  INPUT  believes  that  many,  but 
not  all,  of  the  office  functions  will  be  integrated  within  two  years. 

A "paperless  office"  was  recently  opened  in  Washington,  D.C.,  to 
demonstrate  the  technology  that  is  currently  available.  It  includes  data 
processing,  mass  storage  and  retrieval  of  microfiche,  word  processing, 
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EXHIBIT  V-5 
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EXHIBIT  V-6 


LIKELY  AVAILABILITY  AND  VALUE 
OF  MANAGEMENT  WORKSTATIONS 
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electronic  mail,  dictation  and  communication  equipment.  But  while  the 
devices  have  been  made  "compatible,"  there  is  no  indication  that  the 
office  functions  are  integrated,  efficient,  or  cost-effective. 

The  White  House  is  the  setting  for  another  "office  of  the  future"  effort 
to  demonstrate  what  the  new  technology  can  do,  but  few  definite 
results  of  that  project  have  been  realized  either. 

The  problems  are  basically  not  technological,  but  attitudinal.  Organizations 
do  not  yet  know  how  to  deal  effectively  with  the  radical  restructuring  of  roles 
and  relationships  that  the  "integrated  office"  implies. 

Consequently,  INPUT  recommends  that  users  proceed  slowly  on  this  topic, 
continuing  to  experiment  and  gain  experience  from  the  incremental  combi- 
nation of  functions  as  they  become  available,  but  not  rushing  headlong  into  a 
subject  that  may  require  a major  social  readjustment  before  it  becomes  truly 
effective. 

PERSONAL  COMPUTERS  IN  THE  OFFICE 

Perhaps  no  development  in  recent  times  has  been  so  intriguing  as  the 
widespread  popularity  of  the  personal  computer,  particularly  the  Radio  Shack 
TRS-80,  the  Apple,  and  the  Commodore  Pet.  Selling  for  a base  price  of  about 
$1,000,  they  have  opened  up  a whole  new  market  and  offer  possibilities  within 
the  large  business  organization  that  must  be  investigated. 

The  $1,000-5,000  price  characteristics  of  these  machines  would  make  them 
immediately  desirable  as  low-cost,  local  substitutes  for  the  corporate  RJE  or 
timesharing  service,  or  as  the  basis  for  a kind  of  home-spun  distributed  data 
processing  network— if  certain  business  characteristics  can  be  met. 

Two  advantages  appear  to  be  offered  by  these  machines: 
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A low  cost,  "friendly"  alternative  that  can  be  used  in  the  local  office  to 
solve  local  problems  whose  priority  can't  overcome  the  queue  for 
corporate  DP  resources. 

A convenience  for  the  manager,  salesman,  designer,  or  any  other 
employee  who  frequently  finds  it  necessary  or  advantageous  to  work  at 
home  or  at  least  out  of  the  office. 

• While  this  distinction  may  define  two  different  user  groups,  it  does  not  impose 
different  technical  requirements  upon  the  machines.  Thus,  the  difference  in 
scores  assigned  to  these  two  situations  by  DP  managers  probably  reflects  the 
difference  in  perception  of  work  habits  and  work  requirements,  rather  than 
any  real  difference  in  technology  development. 

• DP  manager  respondents  feel  that  there  is  a high  likelihood  that  personal 
computers  will  be  linked  to  the  corporate  mainframe  from  an  office  environ- 
ment within  the  next  two  years,  and  a very  high  probability  of  this  situation 
occuring  within  five  years,  as  shown  in  Exhibit  V-7. 

Major  software  vendors  feel  it  is  somewhat  less  likely  than  DP 
managers  do,  both  in  the  two-year  and  five-year  periods  — but  they  do 
feel  the  event  has  an  even  or  better  probability  of  happening. 

If  it  does  occur,  it  is  judged  by  DP  managers  to  be  quite  useful, 
achieving  52  out  of  a possible  100  points. 

• The  same  situation,  but  taking  place  from  a home  environment  rather  than 
from  the  office,  is  judged  less  likely,  but  still  50/50  or  better  in  the  two  to 
five  year  timeframe,  as  shown  in  Exhibit  V-8. 

This  mode  is  considered  less  valuable,  worth  only  43  of  100  points. 

• There  is  no  inherrent  reason  why  personal  computers  cannot  be  linked  to 
corporate  mainframes  now,  at  least  in  a 3780  emulation  mode. 
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LIKELY  AVAILABILITY  AND  VALUE  OF  PERSONAL 
COMPUTERS  LINKED  TO  MAINFRAMES  FROM  OFFICE 
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EXHIBIT  V-  8 


LIKELY  AVAILABILITY  AND  VALUE  OF  PERSONAL 
COMPUTERS  LINKED  TO  MAINFRAMES  FROM  HOME 
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At  least  one  company,  Micro-Integration,  Inc.,  of  Friendsville, 
Maryland,  offers  a "black  box"  compatibility  package  that  requires  a 
Z80  or  8080  microprocessor  with  the  S-100  bus,  24K  of  memory,  a 
floppy  disk  and  the  CP/M  operating  system  to  appear  to  the  network  as 
a bisync  IBM  3780  operating  up  to  4800  baud. 

But  the  usefulness  of  this  system  may  stop  right  there  unless  the  user 
also  has  software  written  in  the  micro-COBOL,  micro-FORTRAN,  or  a 
compatible  BASIC  language  subset,  or  is  willing  to  develop  such  a 
package. 

• Other  likely  problems  are  related  to  the  reliability  of  the  personal  computer 
under  commercial  use  conditions  rather  than  less  demanding  home  use;  the 
present  necessity  for  carry-in  or  mail-in  servicing  when  required;  and  the 
unavailability  of  proven,  business-oriented  software  suitable  for  real-life 
companies. 

• INPUT  does  not  see  a groundswel!  of  companies  rushing  to  develop  micro- 
based  software,  even  within  the  five-year  period. 

There  are  too  many  unanswered  opportunities  to  develop  software  for 
other  minicomputer  and  mainframe  applications  that  have  wider  appeal 
and  also  pay  better. 

Thus,  if  personal  computers  do  become  widely  used  within  major 
organizations,  it  will  be  on  a "do-it-yourself"  basis,  rather  than  as  a 
formal  development  effort  of  the  DP  department. 

• The  DP  manager,  however,  would  be  well  advised  to  offer  an  encouraging  hand 
to  users  who  do  want  to  attempt  their  own  personal  computer  development 
effort  by: 

Offering  personal  computer  classes  as  part  of  the  voluntary  training 
curriculum. 
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Sponsoring  or  assisting  in  the  development  of  a personal  computer 
interest  group. 

Providing  whatever  technical  assistance  he  can  offer,  at  least  on  a 
voluntary  basis. 

The  objective  of  all  of  these  activities  is  not  only  to  engender  good  will  and  to 
maintain  a finger  on  the  pulse  of  users  at  the  grass  roots  level,  but  also  to 
foster  a better  understanding  on  the  part  of  the  users  of  what  computers  can 
and  cannot  do,  thus  making  the  users  able  to  assist  in  the  development  of 
larger  systems  in  a more  meaningful  way. 

MISCELLANEOUS  USER  EFFECTIVENESS  AIDS 

Not  in  the  same  category  in  terms  of  the  magnitude  of  improvement  they  may 
offer,  but  nevertheless  valuable  because  they  permit  information  to  be 
interpreted  in  new  ways,  are  the  use  of: 

CRT  graphics. 

CRT  color  displays. 

CRT  touch  panels. 

Simple-to-use  modeling/simulation  tools. 

CRT  color  by  itself  has  not  yet  had  widespread  use,  except  in  certain 
specialized  situations  such  as  process  control,  where  a shift  in  color  could  be 
used  as  an  attention  getting  device. 

Light  pens,  and  in  some  cases  CRT  touch  panels  (which  enable  the  operator  to 
simply  touch  a desired  location  on  the  screen  with  his  or  her  finger,  rather 
than  the  pen),  exist  and  can  be  used  in  conjunction  with  either  a color  or  black 
and  white  screen  to  facilitate  untrained  user  interaction  with  the  computer. 
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• The  use  of  CRT  graphics  and  color  is  considered  to  be  quite  useful  by  the 
majority  of  DP  managers  and  both  they  and  the  software  vendors  feel  use  of 
these  devices  will  be  generally  available,  perhaps  widespread  within  two  years. 

Exhibit  V-9  also  indicates  that  this  is  virtually  certain  to  happen  within 
the  five  year  time  period. 

• However,  other  studies  conducted  by  INPUT  have  not  revealed  any  headlong 
plunge  by  the  mainline  CRT  manufacturers  to  produce  the  numbers  of  color 
terminals  this  situation  seems  to  call  for. 

In  particular,  IBM  does  not  yet  offer  anything  but  monochrome  displays. 

• On  the  other  hand,  INPUT  concurs  that  color  CRT  graphics  will  see  increas- 
ingly more  frequent  use,  particularly  in  combination  with  the  management 
workstation  concept  where  color  and  graphics  easily  conveys  information  that 
is  difficult  to  grasp  in  numerical,  tabular  form. 

• To  drive  these  new  graphic  applications,  easier-to-use  modeling  and  simulation 
packages  are  called  for. 

• Respondents  felt  these  "what-if"  tools  would  be  almost  as  useful  by  themselves 
as  the  color/graphics  capabilities  and  assigned  a usefulness  rating  of  47  points 
to  their  availability,  as  shown  in  Exhibit  V-IO. 

Most  DP  managers  felt  these  tools  would  be  available  within  two  years 
and  certainly  within  five  years. 

Vendors  were  more  cautious,  although  still  optimistic. 
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EXHIBIT  V-  9 


LIKELY  AVAILABILITY  AND  VALUE 
OF  CRT  CRAPHICS/COLOR 
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EXHIBIT  V-10 


LIKELY  AVAILABILITY  AND  VALUE  OF 
HUMAN-ENGINEERED  MODELING  /SIMULATION  TOOLS 
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Several  DP  managers  asserted  that  these  tools  already  exist.  However, 
few  existing  packages  could  be  called  "human-engineered"  or  "easy-to- 
use."  Little  attempt  has  been  made  to  interface  them  with  existing 
data  bases  on  the  front-end  or  with  graphics  display  tools  for  the  on- 
line environment. 

Most  of  the  packages  also  require  extensive  computer  resources,  largely 
due  to  the  many  options  that  are  offered. 

« Hewlett-Packard  has  been  one  of  the  leaders  in  producing  integrated,  menu- 
driven  modeling  and  graphics  software/firmware  on  their  minicomputers  and 
sees  this  as  a growth  area. 

• Microcomputer-based  devices  also  offer  promise  in  offloading  much  of  the 
statistical  processing  to  the  local  level,  allowing  users  to  gain  low-cost 
experience  with  the  techniques. 


B.  CURRENT  INVESTIGATIONS  - EFFICIENCY  AIDS 


• The  difficulty  of  producing  effective  software  centers  mainly  around  the 
complexity  of  the  endeavor,  compared  to  the  limited  ability  of  human  beings 
to  handle  complexity.  (Research  has  demonstrated  that  "seven,  more  or  less" 
is  the  maximum  number  of  intellectual  items  most  people  can  handle  concur- 
rently.) 

• A set  of  principles  has  been  deduced  over  time  which  facilitate  dealing  with 
software  complexity.  These  principles  include; 

Modularity. 

Abstraction. 
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Information  hiding. 


Localization. 

• A number  of  techniques  have  been  developed  that  implement  these  principles 
to  varying  degrees,  including: 

Top-down  Design. 

Modular  Decomposition. 

Data  Abstraction. 

Structured  Programming. 

"Goto-less"  Programming. 

Meta-Stepwise  Refinement. 

Jackson  Methodology. 

• Most  of  these  were  discussed  in  INPUT'S  February  1979,  report  on 
"Performance  Improvement:  User  Techniques  And  Experiences." 

In  addition,  the  use  of  other  potential  efficiency  aids  in  software 
development  were  discussed,  such  as  on-line  program  development  and 
the  programmer's  workbench. 

• This  section  discusses  certain  software  development  aids  which  are  generally 
not  yet  commercially  available  but  which  hold  promise  of  improving  the 
efficiency  of  the  software  development  process. 
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SYSTEMS  WORKBENCH 


The  model  or  inspiration  for  this  device,  which  is  not  known  to  be  in  active 
development  currently,  would  have  certain  analogous  identifiable  advantages 
to  the  "programmer's  workbench." 

Capabilities  of  an  ultimate  programmer's  workbench,  as  conceived  by  its 
designers  at  Bell  Laboratories,  could  include: 

(1)  Generation,  modification,  and  production  of  specifications, 
manuals,  catalogs,  reports,  and  documents  in  general. 

(2)  Creation,  editing,  and  control  of  programs  and  test  data. 

(3)  Compilation,  execution,  and  debugging  of  programs  (either  directly 
or  through  the  host  computer). 

(4)  System  generation,  integration,  and  installation. 

(5)  Regression  testing  and  load  testing  of  subsystems  and  of  the  total 
system. 

(6)  Analysis  and  reduction  of  test  results. 

(7)  Tracking  of  changes  to  the  system  (e.g.,  trouble  reports,  enhance- 
ment requests). 

(8)  Evaluation  and  monitoring  of  system  performance.  Also,  system 
modeling  and  simulation. 

(9)  Conversion  of  data  files  and  the  loading  of  the  data  base  into  the 
host  for  live  operation. 
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(10)  Production  of  lists,  reports,  and  statistics  for  use  by  management 
in  the  control  of  each  phase  in  the  development  and  maintenance 
process. 

• Current  implementations  of  the  programmer's  workbench  do  not  include  all  of 
these  capabilities,  but  nevertheless  provide  the  programmer/analyst  with  a 
tool  to  develop  applications  that  are  not  rigidly  bound  to  any  one  manufac- 
turer's hardware/software  facilities,  by  decoupling  through  a machine-inde- 
pendent set  of  languages,  structures,  and  standards. 

The  benefit  of  this  level  of  abstraction  is  the  production  of  a stable, 
generalized  software  environment  that  accepts  changes  more  gracefully 
and  economically. 

Some  costs  may  be  incurred  in  the  purchase  of  additional  hardware  for 
the  development  machines,  plus  code  and  data  conversions  between  the 
development  machine  and  the  host  machine.  These  are  usually  a 
minima!  percentage  of  the  total  operation,  however,  and  are  well 
compensated  by  the  increased  benefits  received. 

• Extending  these  principles  to  the  earlier  phases  of  the  design  process  would 
produce  a systems  workbench.  This  machine  would  draw  upon  such  other  tools 
as  data  dictionaries,  system  definition  languages,  system  flowcharters,  logic 
checkers,  provability  theorems,  and  the  like  to  automate  as  many  facets  as 
possible  of  the  system  design  process. 

• Respondents  were  mildly  enthusiastic  about  the  usefulness  of  such  a device, 
assigning  it  a total  of  46  points  on  the  usefulness  scale,  while  giving  it  a rating 
of  48  points  on  the  likelihood  of  such  a product  becoming  available  within  two 
years.  This  likelihood  increased  to  62  points  in  the  five  year  period,  as  shown 
in  Exhibit  V- 1 I . 

• Software  vendors,  on  the  other  hand,  feel  that  a product  such  as  this  is  very 
likely  to  appear  within  two  years,  and  almost  a certainty  within  five  years. 
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EXHIBIT  V-11 


LIKELY  AVAILABILITY  AND  VALUE 
OF  SYSTEMS  DESIGNER'S  WORKBENCH 
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The  reluctance  of  DP  managers  to  endorse  such  a device  perhaps  relates  to  the 
generally  small  experience  base  developed  to  date  with  tools  like  the  existing 
programmer's  workbench,  or  Maestro,  or  even  the  underlying  principles  of 
structured  design. 

Some  hesitancy  is  also  due  to  what  is  perceived  as  a high  need  for  (and 
cost  of)  programmer  training  in  the  face  of  benefits  which  are 
uncertain  and  may  not  be  achieved  for  several  years. 

INPUT  concurs  with  the  vendors  that  at  least  one  such  device  will  become 
available  within  two  to  five  years,  and  that  it  will  offer  substantially  improved 
performance  to  those  companies  whose  management  can  see  the  benefits  of 
increased  standardization  these  devices  will  provide. 

AUTOMATIC  PROGRAM  TESTERS 

Many  authorities  use  the  figure  of  50%  as  the  portion  of  the  software 
development  process  that  is  typically  devoted  to  testing  (when  software 
development  is  defined  to  exclude  the  maintenance  and  operation  phase). 

Even  the  smallest  degree  of  efficiency  improvement  in  testing  would  thus 
produce  savings  amounting  to  thousands  of  man  hours  for  large  organizations. 

Testing  is  designed  to  locate  and  reduce  the  number  of  program  errors,  faults, 
and  failures  to  a level  that  is  lower  than  the  tolerance  level  of  the  owner  of  a 
system,  not  to  a "zero  defect"  level. 

Constructive  techniques  that  reduce  errors  are  one  possibility. 

Aside  from  limited  mathematical  applications,  the  "proof  of  correct- 
ness" technique  remains  largely  theoretical  rather  than  practical. 

However,  the  rigor  and  standardization  suggested  by  the  "proof  of  correctness" 
approach  provide  a clue  to  improvement  of  the  testing  process.  Certain  tools 
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have  been  developed  to  assist  at  least  partially  in  the  testing  of  software. 
Among  these  tools  are: 

Program  source  code  analyzers,  which  test  for  structural  flaws  in  a 
program,  such  as  unreachable  statements,  statements  with  no 
successors,  improper  nesting  of  loops,  labels  which  are  unreferenced, 
and  so  forth. 

Another  form  of  source  code  analyzer  concentrates  on  data  flow 
analysis  to  assure  that  variables  are  properly  initialized  and  referenced, 
in  much  the  same  way  that  procedures  are  analyzed  above. 

Run-time  analyzers,  which  monitor  the  behavior  of  a program  during 
operation  by  counting  the  number  of  times  each  statement  is  executed. 

Another  class  of  run-time  analyzers  performs  "Assertion  Checking" 
according  to  rules  for  range,  reasonableness,  state,  and  inverse  supplied 
by  the  designer.  When  violations  of  these  assertions  occur  during  a 
program  run,  they  are  recorded  and  reported  at  the  end  of  the  run. 

Test  data  generators  which  identify  (top-down)  each  separate  path  of 
program  logic  and  construct  appropriate  test  data  to  assure  that  each 
path  is  executed  at  least  once. 

An  alternate  (bottom-up)  approach  proceeds  backward  from  the  end  of 
the  program,  thus  saving  space  for  intermediate  storage  of  variables 
and  results,  but  missing  any  paths  which  do  not  affect  conditional 
expressions. 

Either  of  these  approaches  can  be  combined  with  suitable  program  logic 
to  identify  contradictions  in  data  types,  ranges,  or  inequalities. 
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• DP  managers  only  partially  approve  the  value  of  automatic  program  testers, 
and  express  a low  estimate  of  the  likelihood  of  such  tools  becoming  available 
within  either  the  next  two  or  the  next  five  years. 

Exhibit  V- 1 2 reveals  only  a 37  point  usefulness  rating,  combined  with  a 
34  point  likelihood  of  appearance  within  two  years,  and  a 48  point 
likelihood  of  availability  within  five  years. 

This  reaction  of  DP  managers  is  conditioned  largely  upon  the  disap- 
pointing performance  of  earlier  test  data  generators,  which  required 
excessive  manual  intervention  to  make  them  work,  and  which  did  not 
furnish  any  predictability  or  analysis  of  the  results  they  were  supposed 
to  achieve. 

Vendors  display  a much  higher  62  point  estimate  that  automatic 
program  testers  will  be  commercially  available  within  two  years,  rising 
to  75  points  in  the  five  year  timeframe. 

• In  fact,  automated  program  tester  development  has  been  one  of  the  most 
active  areas  of  research  in  software  development,  much  of  it  funded  by 
government  grants.  Results  have  been  mixed,  largely  because  of  the  immense 
number  of  possibilities  (n-squared)  to  be  tested  in  a program  of  n nodes. 

To  the  extent  that  structured  programming  becomes  more  popular  and 
reduces  the  variability  and  disorder  in  program  structure,  testing  and 
verification  of  source  code  becomes  easier. 

However,  at  least  one-third  of  all  errors  that  occur  in  software  can  be 
traced  to  the  design  and  analysis  phase,  earlier  than  these  testers  are 
able  to  check.  These  errors  can  be  at  least  partially  reduced,  but  only 
through  a more  rigorous,  less  ambiguous  specification  process. 
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EXHIBIT  V-  12 
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A completely  different  approach  to  efficiency  in  software  development  rests 
on  the  assumption  that  for  many  applications  the  only  real  test  is  pragmatic, 
and  therefore  suggests  that  "throwaway"  code  is  most  efficient  — "If  it  doesn't 
work,  throw  it  away  and  try  again." 

Non-procedural  languages  are  one  aspect  of  this  approach  to  a problem.  If 
program  development  time  can  be  cut  from  months  to  days  or  even  hours,  as 
has  been  demonstrated  in  some  instances,  then  all  the  ancillary  efforts  of 
testing  and  documentation  can  be  dispensed  with,  replaced  by  the  single 
performance  test  of  "Does  it  produce  the  desired  results?" 

A less  radical,  but  equally  valuable  aspect  of  automatic  programming  is  one 
that  produces  valid,  machine  dependent  code  for  any  desired  hardware  upon 
receiving  a proper  specification  in  machine  independent  pseudo-code. 

No  distinction  was  made  between  these  two  rather  different  aspects  when 
respondents  were  questioned  as  to  their  estimates  of  the  value  and  likelihood 
of  automatic  programming. 

Exhibit  V- 1 3 indicates  the  largest  disparity  between  DP  managers  and  major 
software  vendors  in  their  opinions  of  how  soon  such  products  might  become 
commercially  available. 

DP  managers  expressed  only  a 27  point  probability  that  these  products 
would  be  on  the  market  within  two  years,  while  software  vendors  voiced 
a 69  point  probability. 

Vendors  still  remained  twice  as  optimistic  as  DP  managers  in  the  five 
year  span,  82  points  to  41  points. 
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EXHIBIT  V-  13 
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Why  this  discrepancy?  Perhaps  because  DP  managers  do  not  see  it  as  a very 
worthwhile  product,  assigning  it  only  34  points  on  the  100  point  usefulness 
scale. 

Granted  that  coding  is  the  smallest  direct  investment  in  the  software 
development  cycle  (20%,  following  both  testing  45%,  and  design  35%),  the 
elimination  of  any  substantial  portion  of  the  coding  effort  would  provide  a 
very  worthwhile  reduction  in  total  cost  of  development. 

Plus,  to  the  extent  that  automatic  coding  would  be  predictably  error- 
free,  the  testing  investment  could  also  be  reduced  or  diverted  to  more 
profitable  uses. 

There  are,  in  fact,  a number  of  commercial  software  products  under  develop- 
ment that  will  facilitate  "automatic  programming"  of  both  varieties  described 
above.  It  remains  to  be  seen  whether  they  will  be  market  successes  in  the 
light  of  DP  managers'  prevailing  attitudes. 

MISCELLANEOUS  TECHNICAL  PRODUCTS 

It  is  no  longer  uncommon  for  a single  organization  to  have  applications  written 
that  use  two  different  DBMS;  e.g.,  IMS  and  TOTAL,  or  TOTAL  and 
SYSTEM/2000.  Some  desirable  applications  would  have  to  access  both  of  these 
data  bases,  but  cannot  without  redundancy  because  there  has  been  no  feasible 
way  to  convert  one  DBMS  to  the  other. 

IBM's  likely  introduction  of  a relational  data  base  also  poses  a dreaded 
question  to  many  DP  managers:  Will  it  be  necessary  to  go  through  a 

conversion  process? 

Anticipating  this  question,  respondents  to  this  study  were  asked  to  estimate 
the  value  and  likely  appearance  of  data  base  conversion  aids  on  the  software 
market.  Their  responses  are  shown  in  Exhibit  V- 1 4. 
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EXHIBIT  V 14 
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Most  DP  managers  felt  that  such  a product  would  be  quite  useful, 
assigning  it  a value  of  47  points  on  the  100  point  usefulness  scale. 

This  relatively  high  rating  was  achieved  despite  the  fact  that  23%  of 
the  managers  said  they  would  "never"  change  to  another  DBMS,  short  of 
an  "act  of  God"  or  a "major  fiasco." 

This  same  group  of  managers  felt  it  is  somewhat  likely  that  data  base 
conversion  aids  would  be  available  within  two  years,  and  slightly  more  likely  in 
the  next  five  years. 

Software  vendors  queried  on  this  subject  expressed  the  opinion  that  it  is 
quite  likely  such  products  will  be  offered  within  two  years,  and  very 
likely  within  five  years. 

The  University  of  Michigan  has  been  working  on  a generalized  data  translation 
package  since  1972,  which  is  table  driven  by  a data  definition  language  that 
describes  physical,  logical,  and  relational  aspects  of  both  the  source  and  target 
data  bases. 

Through  a three  stage  process  (reader/restructurer/writer),  the  package 
has  been  able  to  convert  both  hierarchical  and  network  structures. 
However,  a great  deal  of  manual  analysis  and  definition  is  required. 

Inverted  file  structures,  such  as  those  produced  by  ADABAS  and 
SYSTEM/2000,  pose  additional  difficulties  because  of  the  indices 
involved. 

Economic  feasibility  of  the  approach  is  still  in  question,  although 
technical  feasibility  has  been  demonstrated. 

IBM  is  reported  to  be  working  on  a hardware/software/firmware  solution  for 
the  "E"  and  "H"  series  peripherals  that  would  allow  multiple  definitions  of  the 
data  base  (i.e.,  IMS  and  relational)  each  to  be  accessed  transparent  to  the 
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other.  This  approach,  if  true,  would  solve  a number  of  related  problems  in  one 
quick  stroke. 

One  of  these  related  problems  is  the  desired  capability  for  items  entered  into 
the  data  base  to  be  self-indexing,  based  on  the  internal  content  of  the  item. 

In  a research  context  this  would  be  known  as  "full  text  search" 
capability  and  would  replace  other  indexing  techniques  such  as 
"keyword-in-context"  (KWIC)  or  specified  abstracts. 

Automatic  content  indexing  would  also  be  a valuable  adjunct  to  an 
electronic  mail  system. 

DP  managers  were  divided  on  the  potential  worth  of  this  ability.  Those  who 
thought  it  worthwhile  at  all  tended  to  value  it  highly,  while  the  others  tended 
to  give  it  no  value  at  all. 

The  composite  rating,  as  shown  in  Exhibit  V-15,  is  38  out  of  100  possible 
points. 

Automatic  content  indexing  was  not  thought  to  be  one  of  the  products  that 
would  make  an  early  appearance  on  the  market. 

DP  managers  felt  there  was  a 29  point  probability  of  appearance  within 
two  years,  increasing  to  60  points  within  five  years. 

There  is  already,  however,  at  least  one  product  on  the  market  with  this 
capability.  It  is  known  as  the  "Associative  File  Processor"  (AFP)  produced  by 
Datafusion  Corporation  of  Woodland  Hills,  California. 

AFP  is  a combination  hardware/software  system  attached  to  the  PDP-I  I and 
some  number  of  disk  drives  (from  80  megabytes  to  two  billion  bytes).  Multiple 
systems  can  be  interconnected. 
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EXHIBIT  V-15 
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The  device  utilizes  English-like  queries  entered  interactively  to  produce 
up  to  an  8,192  byte  search  argument  (or,  more  typically,  40-70 
separate,  smaller  queries  processed  concurrently)  that  is  matched 
against  every  word  of  the  data  base  at  a rate  of  up  to  1.2  megabytes 
per  second. 

Retrieval  of  the  first  matching  document  typically  occurs  within  a few 
seconds,  but  a 300  megabyte  disk  can  be  totally  scanned  within  four  to 
five  minutes. 

The  system  sells  for  approximately  $80,000-87,000,  depending  on  the 
amount  of  disk  storage. 

Regarding  improvements  to  the  data  entry  process,  respondents  were 
questioned  about  two  potential  developments.  The  first,  a multi-media  source 
data  converter,  was  described  as  a device  like  an  optical  character  reader  that 
would  automatically  recognize  and  encode  any  alphanumeric  material  it  found 
on  a page  and  would  digitize  any  other  information. 

As  shown  in  Exhibit  V-16,  DP  managers  (with  one  exception)  were  not 
enthusiastic  about  this  capability,  valuing  it  at  only  29  of  100  points,  and 
estimating  only  a 24-27  point  probability  that  it  would  be  available  within  two 
to  five  years,  respectively. 

Software  vendors  were  about  twice  as  optimistic  in  both  the  two  and 
five  year  periods. 

The  exception  was  a DP  manager  of  a bank  who  thought  such  a device  would 
be  uniquely  valuable  in  making  it  possible  to  store  check  images  digitally 
rather  than  micrographically. 
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EXHIBIT  V-16 
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Again,  at  least  one  device  already  exists,  selling  for  less  than  $100,000,  that 
can  scan  and  recognize  virtually  any  printed  material  reading  about  one  page  a 
minute.  From  here  it  is  only  a short  step  to  digitizing  anything  on  the  page 
that  was  not  encoded  as  a character. 

The  device  is  known  as  the  Kurzweil  Reader,  produced  by  Kurzweil  Products 
of  Cambridge,  Massachusetts. 

It  was  originally  developed  with  federal  funding  as  a computerized 
reader  for  the  blind  and  has  been  installed  in  this  capacity  in  the  New 
York  Public  Library  and  several  other  locations. 

It  incorporates  many  patented  algorithms  and  hardware  devices  that 
enable  it  to  discriminate  virtually  any  common  typeface,  organize  these 
characters  into  syllables  and  phonemes,  and  generate  a recognizable 
verbalization  of  the  printed  page. 

As  to  the  other  data  entry  product,  vendors  only  were  asked  their  estimate  of 
how  soon  voice  recognition  software  might  be  available.  The  results  of  this 
survey  are  shown  in  Exhibit  V-17,  and  indicate  only  a medium  likelihood  within 
the  two  year  period  that  does  not  grow  much  stronger  within  the  five  year 
span. 

The  telephone  companies  and  related  product  vendors  have  had  available  for  a 
year  or  more  "speaker-independent"  software  that  can  recognize  the  spoken 
ten  digits  and  a small  number  of  additional  commands. 

The  usefulness  of  this  ability  is  primarily  in  the  area  of  order  entry, 
inventory,  and  applications  dealing  with  banking  and  credit  card  trans- 
actions, as  well  as  the  programming  of  industrial  robots. 

For  wider  applications,  it  will  be  necessary  to  develop  systems  that  can 
recognize  continuous  speech  (rather  than  single  words  separated  by 
pauses)  in  a cost-effective  way.  No  technical  advancements  are 
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EXHIBIT  V- 1 7 
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required,  but  the  cost  ratio  between  continuous  speech  recognition  and 
recognition  of  isolated  words  is  about  7:1.  Thus,  a continuous  voice 
recognition  terminal  now  costs  about  $65,000,  compared  to  under 
$10,000  (per  user)  for  one  which  recognizes  up  to  2 I isolated  words  for 
eight  users  simultaneously. 

Obviously,  neither  alternative  compares  favorably  with  a Touch-Tone 
keypad,  except  in  very  specialized  circumstances.  But  prices  are 
dropping  at  a rate  that  could  make  voice  recognition  input  widely 
feasible  within  two  to  three  years. 


- 152  - 


© 1979  by  INPUT,  Palo  Alto,  CA  04303.  Reproduction  Prohibited 


INPUT 


APPENDIX  A:  INTERVIEW  SCHEDULE 


APPENDIX  A: 


INTERVIEW  SCHEDULE 


INTERVIEWEE  TYPE 

NUMBER 

OF 

INTERVIEWS 

DP  MANAGERS  OF  LARGE-SCALE 
INSTALLATIONS  (370/158  MINIMUM) 

26 

1 MAJOR  SOFTWARE  VENDORS 

16 
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APPENDIX  Bs  SURVEY  QUESTIONNAIRES 
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INPUT  is  preparing  a report  on  future  developments  in  software  and  how  users  should 
prepare  for  them.  We  see  major  developments  in  the  next  five  years  in  the  use  of 
distributed  data  processing  (DDP),  database  management  systems  (DBMS),  non-procedural 
languages,  and  integration  of  office  systems  (word  processing,  electronic  mail). 


A.  GENERAL 


S.  The  information  ! have  shows  that  you  have  (#) IBM  (Model) 

operating  under . Is  that  correct? 


2.  On  a scale  of  I to  5,  how  centralized/decentralized  is  your  company? 

Very  centralized -4 — ^Very  decentralized 


a.  Generally  I 

b.  Managerially  I 

c.  Financially  I 

d.  With  respect  to  EDP  1 


2 3 4 

2 3 4 

2 3 4 

2 3 4 


5 

5 

5 

5 


e.  Will  there  be  any  changes  in  your  company's  centralization/decentralization 
philosophy?  □ Yes  □ No.  How  and  why? 


f.  How  long  does  your  company  usually  wait  before  adopting  new  developments 
in  data  processing?  □ Among  the  earliest  □ First  one-third 
□ Average  P Last  one-third  □ Near  the  end. 


B.  NEW  DEVELOPMENTS 


3.  What  are  the  three  to  five  most  important  factors  that  cause  you  to  make 
major  changes  or  new  developments  in  software? 
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4.  In  your  opinion,  how  likely  will  new  products  be  available  in  the  following 
areas  in  the  next  2-5  years,  and  how  useful  would  they  be  to  you? 


Likelihood  of  Availability 

Usefulness 

Within 

2 Yrs. 

Within  5 Yrs. 

H 

M 

L 

H 

M 

L 

H 

M 

L $(K) 

a. 

Non-procedural  Languages 

□ 

□ 

□ 

□ 

O 

□ 

□ 

□ 

□ 

b. 

Relational  Data  Base 

□ 

o 

o 

O 

□ 

□ 

□ 

□ 

□ , 

c. 

Data  Base  Conversion  Aid 

□ 

□ 

□ 

□ 

□ 

□ 

O 

□ 

□ _ 

d. 

Word  Processing  Linked  to  DP 

□ 

□ 

□ 

□ 

0 

□ 

o 

D 

□ 

e. 

Automatic  Content  Indexing 

O 

0 

a 

0 

D 

D 

o 

0 

□ 

f. 

Graphics/Color  CRT  Packages 

o 

D 

□ 

□ 

O 

O 

o 

O 

□ 

g- 

User  oriented/human  engineered 

□ 

o 

□ 

D 

D 

0 

o 

o 

□ 

modeling/simulation  packages 

h. 

Automatic  program  testers 

□ 

0 

□ 

0 

□ 

0 

□ 

□ 

□ 

i. 

Systems  Analysis/Design  Aids 

o 

□ 

□ 

□ 

0 

O 

□ 

□ 

□ 

(Systems  Workbench) 

j- 

Automatic  Programming 

□ 

o 

o 

O 

O 

O 

□ 

0 

□ 

k. 

Personal  Computers  Linked 

to  Large  Mainframes 
from  home? 

□ 

□ 

□ 

□ 

O 

O 

D 

o 

n 

from  office? 

O 

□ 

o 

o 

O 

□ 

□ 

o 

o 

1. 

Multi-media  source  data 

□ 

o 

0 

o 

O 

□ 

□ 

□ 

□ 

converters 

m. 

Electronic  Mail  Systems 

O 

□ 

□ 

0 

□ 

□ 

□ 

□ 

□ 

n. 

Integrated  Office  Systems 

a 

0 

o 

a 

□ 

O 

□ 

□ 

□ 

(Telephone,  Copying,  Filing,  DP) 

o. 

Management  Workstations 

□ 

o 

o 

o 

O 

O 

□ 

D 

□ — 

p. 

Teleconferencing 

□ 

o 

□ 

□ 

'□ 

O 

□ 

□ 

□ __ 

5.  What  other  software  areas  do  you  feel  are,  or  should  be,  under  development 
during  the  next  five  years? 
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6.  a.  How  and  by  whom  are  software  development  priorities  decided  now? 

b.  What  is  the  user's  role? 

□ Initiate  request  only 

□ Moderate  involvement  during  development. 

D Heavy,  continuous  involvement  during  development. 

□ Project  leader. 

□ Active  role  in  EDP  priority  steering  committee 

□ 

c.  Is  the  user's  current  level  of  involvement  satisfactory?  Yes  □ 
No  O 

How  will  it  change  in  the  next  2-5  years? 


7. 

What  is  your  attitude 
toward  software  packages? 

For  Systems 
Oper.  Prods. 

For  Systems 
Utiliz.  Prods. 

For  Implem. 
Sys.  Prods. 

For  Applic. 
Sfw.  Pkgs. 

a. 

Prefer  it 

O 

□ 

□ 

□ 

b. 

Consider  it 

o 

□ 

a 

o 

c. 

Won't/Can't  use  it 

o 

□ 

□ 

o 

If  (a) 

or  (b),  do  you  prefer 

d. 

Standard,  "off-the-shelf" 
packages 

□ 

o 

□ 

□ 

e. 

Semi-custom,  parametized 
packages 

□ 

□ 

o 

□ 

f. 

Use  of  a computing 
services  package 

o 

o 

□ 

0 

g- 

Fully  customized 

o 

□ 

o 

□ 
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How  do  you  find  out  about  software  packages  now? 

b.  How  do  you  judge  their  quality? 

c.  What  improvements  to  their  selling  process  would  make  your  buying 
decisions  more  efficient? 


d.  Do  you  feel  you  are  getting  good  value  for  your  software  dollar  with 
respect  to  each  of  the  following? 


Underpriced 

Priced 

Right 

Overpriced 

No 

Opinion 

Systems  software 

□ 

□ 

□ 

□ 

Utility  software 

□ 

□ 

□ 

□ 

Applications  software  O 

o 

□ 

□ 

a.  Who  has  final  approval  to  purchase  outside  software  in  your  company? 

Mgr.  of  Oper., 

Dir.  of  EDP 

Non-EDP 

VP, 

Prog.,  etc. 

Div.  Head 

etc. 

Under  $5,000 

□ 

□ 

□ 

□ 

$5,000-$20,000 

□ 

□ 

□ 

□ 

$20, 000- $50, 000 

□ 

□ 

□ 

□ 

$50,000-$  100,000 

□ 

□ 

□ 

□ 

Above  $ 100,000 

□ 

□ 

□ 

□ 

b.  Who  else  is 

nvolved  in  the  process? 

c.  Must  these  items  be  specifically  identified  in  the  budget  if  above  a 

certain  dollar  level?  Q Yes  □ No.  What  level?  $ . 

d.  Must  there  be  a formal  cost  justification?  □ Yes  D No 

□ Only  above  $ . 

e.  What  justification  is  normally  used?  □ ROI  □ Discounted  cash 

flow  □ Replacement  personnel  cost  □ Improved  time  efficiency/capacity 
utilization  □ Life  cycle  cost  □ Other  (describe) 
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C.  LANGUAGES 


10.  a. 


b. 


c. 


d. 


e. 


What  percentage  of  your  total  applications  are  written  in: 

COBOL % FORTRAN  % PL/ 1 % 

Assembly  Language % (Other) % 

What  percentage  of  existing  applications  use  structured  techniques?  % 

What  percentage  of  new  applications  use  structured  techniques? % 

If  you  are  using  structured  techniques  now,  what  degree  of  improvement 
have  you  seen  in:  reliability? 

easier  maintenance? 

on  time/on  cost  development? 

better  match  to  specifications? 

Which  techniques  are  you  using? 


f.  Do  you  consider  structured  techniques  □ a great  improvement 
in  systems  development  P useful  in  certain  circumstances 
□ only  a fad  □ not  useful. 


S la.  What  do  you  think  will  be  the  impact  of  new  hardware  technology  on  software 
during  the  next  2-5  years? 


b.  Will  the  impact  be  greater  on  systems  software  O or  applications 
software  □ or  about  the  same  D ? Describe,  if  possible. 

12a.  Do  you  have  online  program  development  facilities? 

□ Yes  □ No.  If  yes,  for  how  long?  years. 

If  no,  when  do  you  plan  to  install  them?  In years. 

b.  What  facilities  do  you  or  will  you  use?  □ TSO  □ CMS 

□ Wylbur  □ ROSCOE  □ Maestro  □ 

c.  How  did  (will)  you  justify  using  them? 


d.  Were  the  results  as  expected?  D better  Q worse  D as  expected. 
Please  describe. 
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D.  DBMS 

I 3a.  Which  DBMS  are  you  now  using?  DIMS  □ Total  □ IDMS  □ Adabas 

O Model  204  □ System  2000  □ DMS  □ 

b.  How  long  have  you  used  it?  

14.  a.  How  many  separate  data  bases  do  you  have?  

b.  What  total  size?  MB 

15a.  Would  there  be  any  advantage  to  combining  them?  □ Yes  O No  (to  #16) 

b.  If  yes,  describe 

c.  If  yes,  what  has  prevented  you  from  doing  it?  □ Technical  factors 
□ Financial  factors  □ Other  priorities 

o 

d.  When  will  you  combine  them?  In years. 

16.  Have  you  experienced  performance  or  other  problems  using  the  DBMS  in  specific 
situations?  □ Yes  □ No  (skip  to  # 1 7) 

a.  If  yes,  describe 


bo  How  do  you  think  this  problem  could  be  relieved? 

17a.  Will  you  require  a distributed  data  base?  Q Yes  □ No  (to  #18) 

b.  By  when?  

c.  If  yes,  how  will  you  maintain  it?  □ Nightly  batch  update  of  central 
DB,  then  download  subset  to  nodes. 

O Periodic  polling  of  nodes  by  central  host. 

□ Non-redundant  DB,  backed  up  and  maintained  locally. 

□ Other,  describe: 
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18a. 


19. 


E. 


20. 


21. 


d.  Who  will  furnish  the  software  for  maintaining  the  DB? 

□ Hardware  vendor  □ DBMS  vendor  □ Outside  consultant 
O RCS  vendor  □ Ourselves 

What  would  cause  you  to  change  to  another  DBMS? 

b.  Would  you  require  availability  of  a conversion  aid  as  part  of  your  selection 
criteria?  □ Yes  □ No 

a.  Have  you  investigated  relational  data  bases  for  your  situation? 

□ Yes  □ No  Not  familiar  with  them  (skip  to  #20) 

b.  What  advantages/disadvantages  would  they  have  for  your  situation? 


DDP 


Are  you  considering,  or  do  you  now  have,  distributed  data  processing  (DDP)? 
O Yes  □ No.  If  no,  go  to  question  25. 


What  configuration  do  you  intend  to  use  for  DDP?  O Main  host-driven/star 
network  □ Stand-alone  minis  loosely  coupled  to  central  facility  and  each 
other  O Other  (describe) 
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22.  What  hardware  and  operating  systems  will  you  use  for  DDP? 


a.  At  the  central  site:  (//)  IBM  Model  under 

□ OS/VSI  □ MVS  □ DOS/VS,  or  (//)  (Moke,  Model) 

under . 

b.  At  the  nodes:  (#) IBM  Model 

under , or  (#) (Make,  Model) 

under 


c.  Would  you  consider  User  Site  Hardware  Service?  □ Yes  □ No 
Why  or  why  not? 


23.  a.  What  factors  led  you  to  choose  your  DDP  hardware  and  configuration? 

□ already  in  place  □compatible  with  central  site  □ most  cost  effective 

□ easiest  to  use  □ proven  successful  in  a situation  similar  to  ours 

□ operating  software  already  developed 

b.  What  kind  of  justification  did  you  use  to  select  DDP? 


24.  a.  What  type  of  applications  will  be  or  could  be  operated  remotely? 


Could  be 


Will  be 


□ □ 


General  financial  & administrative  (A/R,  A/P,  G/L,  Payroll, 
etc.) 


□ 

□ 

□ 


□ Sales  and  marketing  (0/E,  Sales  Analysis,  etc.) 

O Industry  specialties  (Inventory,  Scheduling,  Demand  Deposit 
Accounting,  Student  Records,  etc.) 

□ Scientific  and  Engineering  (T/S,  OR,  CAD,  etc.) 
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24.  b.  Who  will  furnish  the  software  for  these  applications? 


General  financial 
and  administrative 

Use 

Existing 

Software 

Rewrite 

Software 

Centrally 

Rewrite 
Software 
at  Nodes 

Use 

Turnkey 

Sys,/Sfw. 

Pkg./RCS 

□ 

□ 

□ 

□ 

Sales  and  marketing 

„ □ 

□ 

□ 

□ 

Industry  Specialties 

□ 

□ 

□ 

□ 

Scientific  & Engineering 

□ 

□ 

□ 

□ 

How  soon  will  they  be  in  operation? 

Now 

In  1 yr.- 

In  2 yrs. 

In  yrs. 

General  financial 
and  administrative 

□ 

□ 

□ 

— 

Sales  & Marketing 

□ 

□ 

□ 

— 

Industry  Specialties 

□ 

□ 

□ 

— 

Scientific  & Engineering 

□ 

□ 

□ 

— 

24d.  What  were  the  reasons  for  choosing  these  applications? 


25.  What  do  you  think  is/are  the  greatest  problem(s)  with  DDP  right  now? 

O Too  expensive  for  □ communications  Q hardware 

□ people  □ software 

O Too  much  risk  of  losing  control 

O Too  many  unresolved  technical  problems 

o 

□ 

26a.  Do  you  consider  turnkey  systems  an  advantage  □ or  a threat  □ ? 

Why? 


b.  Do  you  consider  minis/micros/personal  computers  an  advantage  □ 
or  a threat  Q ? Why? 
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F.  PERSONNEL 


27.  a.  How  much  training  did  (will)  your  programming  improvement  techniques 
require? 

b.  Is  this  D more  □ less  □ about  the  same  as  you  expected  originally? 

c.  Is  the  training  for  EDP  staff  □ voluntary  □ required? 

d.  Is  the  training  □ in-house  □ from  IBM  □ from  a training  vendor? 

e.  Do  users  also  receive  training?  □ voluntary  □ required  □ none. 


28.  a. 


b. 


c. 


d. 


Are  you  experiencing  an  EDP  personnel  shortage?  □ none 

□ mild  □ moderate  D severe. 

What  is  your  turnover  level  now?  % per  year. 

In  the  next  1-2  years,  do  you  expect  the  shortage  to: 

□ increase  □ decrease  D stay  the  same. 

D moderately  D severely 

In  the  next  5 years,  do  you  expect  the  shortage  to: 

□ increase  □ decrease  D stay  the  same. 

□ moderately  D severely 

What  strategies  are  you/will  you  use  to  cope? 

□ more  productivity  through  training  and/or  incentives 

□ more  productivity  through  technology 

□ offload  development  to  users 

□ more  use  of  packaged  software  for  □ systems  □ applications 

□ stretch  out  development  time 


e.  What  productivity  aids  would  you  like  to  see? 


THANK  YOU  VERY  MUCH.  WE  WILL  SEND  YOU  A SUMMARY  OF  THE  RESULTS 
IN  ABOUT  60  DAYS. 
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1.  Sales  Approach 


a.  What  is  the  typical  sales  strategy  used  (eg.  send  brochure,  qualify 
via  phone,  make  product  presentation,  work  with  groups  affected  by 
product,  close)? 


b.  Does  the  sales  strategy  vary  by  product?  ( ) Yes  ( ) No 
If  so,  how? 


c.  What  is  your  sales  approach  for  different  countries? 


Country /Area 

Direct  Sales 
% 

Agent 

% 

Joint 

Venture 

/> 

Telephone  & 
Mail  Sales 
% 

U.S . A. 

Canada 

Europe 

Middle  East 

Far  East 

Mexico 

Central  and 
South  America 

Others 
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d.  Who  do  you  call  on  to  sell? 


Call 

Title/ 

Position 

Number  of 
Calls 

Vendor 

Presentation 

Overview 

Presentation 

Technical 

Presentation 

1 

2 

3 

4 

5 

6 

7 

e.  Is  this  shifting?  ( ) Yes  ( ) No  If  yes,  how? 


f.  Does  the  product  have  an  influence  on  who  your  sales  force  call  on? 
( ) Yes  ( ) No  If  yes,  how? 


g- 


How  many  calls  are  made  before  a prospect  is  dropped? 
Before  a sale  is  closed? 
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Marketing 


a.  How  do  you  know  if  and  when  to  develop  a new  product,  or  to  modify 
and/or  extend  existing  products?  Please  rate  the  following  factors 
in  degree  of  importance  in  these  decision  processes  (5  is  most 
important,  1 is  not  importaiit). 


Factor 

Develop  a 
New  Product 

Modify  and/or 
Extend  Existing 
Products  | 

Requirement  perceived  by  sales  force 
and  not  offered  by  competitor 

Loss  to  competition 

i 

Result  of  In-house  Development 

i 

Market  Research  performed  In-house 

Market  Research  performed  by 
Consultant 

New  hardware  introduced  by  hardware 
manufacturer 

Trend  to  on-line  processing 

Decision  to  specialize  by  industry 

Other  (describe) 
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b . 


How  are  your  prices  determined  for  your  package,  maintenance 
and  professional  services? 


Method 

Package 

1 

Maintenance 

• 

Professional 

Services 

Cost  plus  profit  percent 

Competition 

What  the  market  will  bear 

Cost  plus  fixed  fee 

Time  and  materials 

Other  (describe) 
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Product  Statistics 
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Competitors 

Revenue 

Estimate 

Competitors 

Where 

Advertised 

1 

1978 

Revenue 

o -a 

•H 

jj  a 

cc  6 >- 

O (-1  0)  c 
•H  O 4-J  3 

« — ( CO  4- 

a u- 

C-  CO  c 

< cr 

Hardware 

i 

Number  of 
Installation: 

Price 

Software 

Product 
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Application  Products  Systems  Products 

- Cross  Industry  Products  . Systems  Operations  Products 

- Industry  Specialized  Products  - System  Utilization  Products 

- Implementation  Systems  Products 


CATALOG  NO.  I'mIsIfIwI  1~T~1 


4#  Personnel  and  Cost  Statistics 


Number  of 
People 

Percent 

Female 

Turnover 

Percentage 

Compensat ion 
Cost  as  a % 
of  Revenue 

Total  Cost 
as  a % 
of  Revenue 

Sales 

Sales  Support 

Marketing 

Total  Sales  & 
Marketing 

Development 

Maintenance 

5.  Advertising 


Medium/ 

Source 

Number  of 
Leads 
Generated 

Quality  of 
Leads 

Generated* 

Typical 
Ad  Size 

Type  of 
Ad  Used** 

Products 

Advertised 

* Measures  on  a 1 to  5 scale  where  5 is  the  highest  quality. 
**  Serious  advertisement  or  comical  advertisement. 


a.  How  do  you  measure  the  quality  of  leads  generated? 
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Describe  your  training  programs. 


CATALOG  NO.  FmI  sIf?U~TT 
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What  technological  threats  do  you  see  for  your  products  (such  as  micro 
computers,  communications,  mass  memory,  inexpensive  memory,  structured 
programming) ? 


What  impact  will  DDP  have  on  your  products? 


What  impact  will  minicomputers  have  on  your  business? 


What  impact  will  turnkey  systems  have  on  your  business? 


CATALOG  NO.  f^TSf^l  f ! j 


Please  specify  plans  and  likelihood  of  development  for  the  following: 

Likelihood  of  Development 


a.  Non-procedural  languages_ 


Within  2 Years  Within  5 Years 


H M 


H M 


b.  Relational  Data  Base 


c.  Data  Base  Conversion  Aids 


H M 


H M 


H M 


H M 


d.  Linking  Word  Processing  to  Data 
Processing  


H M 


H M 


e.  Automatic  File  Indexing 


H 


ML  H M L 


Graphics/color  CRT  output 
packages  


H M 


H M 


User  oriented/human  engineered 
modeling  or  simulation  packages 


H M 


H M 


h.  Automatic  Program  Checkers/Testers  H 


M 


H M 


i.  Systems  Design  Aids  (systems 
workbench) 


H M 


H M 


j.  Automatic  Coding/programming 


H 


ML  H M L 


Linking  personal  computers  to 
large  mainframes 


H 


M L H M L 


1.  Multi-media  source  data  con- 
version 


H 


ML  H M L 
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Within  2 Years  Within  5 Years 


ra.  Electronic  Mail 


H ML  H ML 


n.  Management  Workstations 

H ML  H ML 


o.  Linking  office  systems  H ML  H ML 

(telephone,  copying,  filing) 
to  data  processing 


p.  Teleconferencing_ 


H 


M L 


H 


M L 


q.  Distributed  Data  Bases 


H ML  H ML 


r.  Voice  recognition  and 
conversion 


H 


M L 


H 


M L 


s.  Other 


H 


M L H M L 


12.  What  other  software  (not  suitable  for  development  by  your  company)  do  you 
feel  should  be  under  development? 


13.  Technical  Considerations 

a.  Have  your  program  development  methods  changed  in  the  last  two  or  three 
years?  ( ) Yes  ( ) No 

If  so,  how? 


b.  What  changes  do  you  foresee  in  program  development  methods  in  the 
next  five  years? 
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c.  How  important  is  the  concept  of  a data  base  to  your  products? 


Will  this  importance  change  in  the  next  two  or  three  years? 
( ) Yes  ( ) No  If  so,  how? 


d.  How  important  is  security  in  your  products? 


Do  you  expect  this  to  change  in  the  next  two  or  three  years? 
( ) Yes  ( ) No  If  so,  how? 
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14.  What  are  current  major  constraints  to  growth  for  systems  software 
vendors?  Rate  each  constraint  in  degree  of  importance  where  5 is 
a major  constraint  and  1 is  not  a constraint. 

4 


Constraint 

Rating 

User  budget 

User  resistance  to  buying  software 

Inadequate  marekting  by  vendor 

Product  Design 

Product  Quality 

Product  documentation 

Product  Training 

Industry  Image 

Technological  uncertainty 

Vendor  budget 

Other 

15.  What  are  the  major  unmet  user  needs? 


16.  Send  product  literature. 
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